- The life of a bug \ud83d\udc1c<\/a><\/li>
- PR workflow \ud83d\udcdc<\/a><\/li>
- Web Preview \ud83d\udd78<\/a><\/li>
- Fastlane \ud83d\udca8<\/a><\/li>
- Release & prod workflow \ud83d\ude80<\/a><\/li>
- More tricks for your CI \ud83e\uddbe<\/a><\/li><\/ul>\n\t\t\t<\/div>\n\t\t<\/div><\/div>\n\n\n\n\n
The life of a bug \ud83d\udc1c<\/h2>\n\n\n\n
Let’s start by quickly going over our process of managing and fixing bugs.<\/p>\n\n\n\n
- \n
- A bug (or feature request) gets reported and a task is created in ClickUp<\/li>\n\n\n\n
- The task is assigned to a developer and fixed in a PR against the staging branch<\/li>\n\n\n\n
- The CI runs all tests, builds the app, deploys a web preview, and uploads everything to the ClickUp task<\/li>\n\n\n\n
- Our QA team verifies the fix and if it is good, the task is marked as done<\/strong><\/li>\n\n\n\n
- The PR gets merged into staging automatically<\/li>\n\n\n\n
- The staging branch gets built and deployed to our internal TestFlight<\/li>\n\n\n\n
- Every Wednesday a release branch is created, built, and tested<\/li>\n\n\n\n
- On Fridays, we create a release on GitHub and the CI deploys the release to the App Store and Play Store.<\/li>\n<\/ol>\n\n\n\n
A ClickUp task contains everything about the bug. We use Custom Statuses<\/a> like In Progress or Code Review to keep track of the bug. The CI workflows change the status automatically. Custom Fields<\/a> contain additional information like who reported the bug, who works on it when it will be released etc.<\/p>\n\n\n\n\n\n
PR workflow \ud83d\udcdc<\/h2>\n\n\n\n
The first two steps outlined above are not really CI-related, but the third one is interesting…<\/p>\n\n\n\n
Our
development<\/code> workflow runs for any PR. It checks lints, formatting and runs all tests before it starts building the Android and iOS artifacts.<\/p>\n\n\n\nname: development\non: pull_request\njobs:\n cancel:\n name: 'Cancel Previous Runs'\n runs-on: ubuntu-latest\n timeout-minutes: 3\n steps:\n - uses: styfle\/cancel-workflow-action@0.9.1\n with:\n access_token: ${{ github.token }}\n check:\n name: Check formatting\n runs-on: ubuntu-latest\n needs: cancel\n timeout-minutes: 5\n steps:\n - uses: actions\/checkout@v2\n - name: Setup Flutter\n uses: subosito\/flutter-action@v1\n - name: Install dependencies\n run: flutter pub get\n - name: Check formatting\n run: flutter format --dry-run . --set-exit-if-changed\n - name: Check lints\n run: flutter analyze\n - name: Run tests\n run: flutter test\n# build, post task message etc.<\/pre>\n\n\n\nWhen a build is successful, the CI will post a message in the linked task. QA Engineers can go to the PR, download the build artifacts or use the web preview.<\/p>\n\n\n
\n![\"The](\"https:\/\/clickup.com\/blog\/wp-content\/uploads\/2022\/01\/bot-message-1400x801.png\" "\\"\\"")
An automated CI message posted in the linked ClickUp task after a successful build<\/p><\/figcaption><\/figure><\/div>\n\n\n
Setting up Flutter on the CI runner \ud83d\udee0<\/h3>\n\n\n\n
We use the well-known GitHub action subosito\/flutter-action<\/a> to set up Flutter on the CI. By default, it will install the latest stable Flutter release. To avoid breaking your CI workflows when a new Flutter version is released, you should specify the version manually.<\/p>\n\n\n\n
steps:\n- uses: actions\/checkout@v2\n- uses: subosito\/flutter-action@v1\n with:\n flutter-version: 2.8.1<\/pre>\n\n\n\n
If you have multiple workflows, it is better to store the flutter version in a file. We use
FLUTTER_VERSION<\/code> in the root of the repository.<\/p>\n\n\n\nsteps:\n- uses: actions\/checkout@v2\n- name: Read FLUTTER_VERSION\n id: get-version\n run: echo \"::set-output name=version::$(cat FLUTTER_VERSION)\"\n- uses: subosito\/flutter-action@v1\n with:\n flutter-version: ${{ steps.get-version.outputs.version }}<\/pre>\n\n\n\nAnother easy solution is to store the Flutter version as GitHub secret and access it using
{{ secrets.FLUTER_VERSION }}<\/code>.<\/p>\n\n\n\n\n\nWeb Preview \ud83d\udd78<\/h2>\n\n\n\n
Thanks to Flutter’s ability to run on the web, we can create a fully functional web preview of pull requests. Using the device_preview<\/a> package, the device size and settings can be adjusted.<\/p>\n\n\n\n
The preview has proven to be very useful and is not only used by our QA team. Designers and Product managers also like it to quickly iterate on new features.<\/p>\n\n\n
\n![\"Fully](\"https:\/\/clickup.com\/blog\/wp-content\/uploads\/2022\/01\/CleanShot-2022-01-20-at-19.40.42@2x-1400x1346.png\")
via Flutter<\/p><\/figcaption><\/figure><\/div>\n\n\n
How to create a web preview \ud83d\udc36<\/h3>\n\n\n\n
To get started, make sure that your app is compatible<\/a> with Flutter web\u2014not all APIs are supported. <\/p>\n\n\n\n
In our app, for example, we needed to disable push notifications and web sockets.<\/p>\n\n\n\n
This sample workflow builds a web preview of your Flutter app and uploads it to an S3 bucket. We use an
ENABLE_DEVICE_PREVIEW<\/code> environment variable to disable thedevice_preview<\/code> in production.<\/p>\n\n\n\nbuild-preview:\n name: Build preview\n runs-on: ubuntu-latest\n env:\n AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}\n AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}\n steps:\n - uses: actions\/checkout@v2\n - name: Setup Flutter\n uses: subosito\/flutter-action@v1\n - name: Install dependencies\n run: flutter pub get\n - name: Build web\n run: flutter build web --release --dart-define ENABLE_DEVICE_PREVIEW=true\n - name: Fix base href\n uses: jacobtomlinson\/gha-find-replace@0.1.4\n with:\n find: '<base href=\"\/\">'\n replace: '<base href=\"\/flutter-preview-${{ github.head_ref }}\/\">'\n include: build\/web\/index.html\n - name: Deploy to S3\n uses: reggionick\/s3-deploy@v3\n with:\n folder: build\/web\n bucket: yourbucket\/flutter-preview-${{ github.head_ref }}\n bucket-region: us-west-2\n no-cache: true<\/pre>\n\n\n\nThe
Fix base href<\/code> step is needed because the preview will not be at the root of the bucket.<\/p>\n\n\n\nAnd some code to conditionally enable the
device_preview<\/code>.<\/p>\n\n\n\nimport 'package:device_preview\/device_preview.dart';\nconst _preview = bool.fromEnvironment('ENABLE_DEVICE_PREVIEW', defaultValue: false);\nvoid main() => runApp(\n DevicePreview(\n enabled: _preview,\n builder: (context) => MyApp(),\n ),\n)<\/pre>\n\n\n\nEnvironment variables are a powerful tool and allow Flutter’s tree shaking algorithm to drop debug code for release builds.<\/p>\n\n\n\n\n\n
Fastlane \ud83d\udca8<\/h2>\n\n\n\n
Fastlane greatly simplifies building, signing, and deploying Flutter apps. It manages our certificates, provisioning profiles, and other settings. We use GitHub secrets to store passwords and tokens securely.<\/p>\n\n\n\n
Useful Fastlane actions:<\/p>\n\n\n\n
- \n
- fastlane match<\/a> to create and store iOS keys and profiles in a GitHub repository<\/li>\n\n\n\n
- build_app<\/a> to build iOS and Android apps<\/li>\n\n\n\n
- upload_to_testflight<\/a> and deliver<\/a> to deploy iOS builds<\/li>\n\n\n\n
- upload_to_play_store<\/a> to deploy Android builds<\/li>\n<\/ul>\n\n\n\n
Sample iOS dev build \ud83c\udf4f<\/h3>\n\n\n\n
platform :ios do\n desc \"Create a dev build\"\n lane :build_dev do\n setup_ci\n api_key = app_store_connect_api_key(\n key_id: ENV[\"IOS_KEY_ID\"],\n issuer_id: ENV[\"IOS_ISSUER_ID\"],\n key_content: ENV[\"IOS_APP_STORE_API_KEY\"],\n )\n match(\n type: \"development\",\n app_identifier: [\"com.example.mobile\"],\n api_key: api_key,\n git_basic_authorization: Base64.strict_encode64(ENV[\"GH_USER_TOKEN\"])\n )\n build_app(\n workspace: \"Runner.xcworkspace\",\n scheme: \"Runner\",\n export_method: \"development\",\n export_options: {\n method: \"development\",\n compileBitcode: false,\n provisioningProfiles: { \n \"com.example.mobile\" => \"match Development com.example.mobile\"\n }\n }\n )\n end\nend<\/pre>\n\n\n\nDon’t forget
setup_ci<\/code> it will save you from weird errors \ud83d\udc7e. Learn more about Fastlane for Flutter apps<\/a>.<\/p>\n\n\n\nAndroid signing \ud83d\udd12<\/h3>\n\n\n\n
The easiest way to sign Android release builds securely is to store the tokens as GitHub secrets and use environment variables and a temporary
key.jks<\/code> created by the CI:<\/p>\n\n\n\nandroid {\n \/\/ ...\n signingConfigs {\n release {\n storeFile file('key.jks')\n storePassword System.env['ANDROID_STORE_PASSWORD']\n keyAlias System.env['ANDROID_KEY_ALIAS']\n keyPassword System.env['ANDROID_KEY_PASSWORD'] \n }\n }\n}<\/pre>\n\n\n\nWe store the
key.jks<\/code> as base64 encoded string in Github Secrets and decode it in the workflow:<\/p>\n\n\n\n- name: Decode Android Keystore\n uses: timheuer\/base64-to-file@v1.1\n with:\n fileName: 'android\/app\/key.jks'\n encodedString: ${{ secrets.ANDROID_STORE_CONTENT }}<\/pre>\n\n\n\n\n\nRelease & prod workflow \ud83d\ude80<\/h2>\n\n\n\n
The
pre-release<\/code> workflow runs for branches that start withrelease\/v<\/code>. It strips all debugging and internal code to make sure we test the same code that will be released.<\/p>\n\n\n\nname: pre-release\non:\n push:\n branches:\n - 'release\/v*'\n# build, test, and post slack message<\/pre>\n\n\n\n
Additionally, the
pre-release<\/code> workflow posts to various Slack channels to notify QA and marketing teams about a new release using incoming webhooks<\/a>.<\/p>\n\n\n\nAfter everything is tested thoroughly, we create a release on GitHub that triggers the
prod<\/code> workflow. It builds and signs the App with production certificates and sends it to the App Store.<\/p>\n\n\n\nname: prod\non:\n release:\n types:\n - created\n# build and deplo<\/pre>\n\n\n\n\n\n
More tricks for your CI \ud83e\uddbe<\/h2>\n\n\n\n
If you use the push trigger for GitHub Actions, you will likely run into problems if there are multiple pushes to the same branch in quick succession. More than one instance of the workflow will start and eat build minutes or cause other problems.<\/p>\n\n\n\n
- \n
- We recommend using the Cancel Workflow Action<\/a> to cancel all previous instances of the workflow<\/li>\n\n\n\n
- If you are looking for an easy and maintainable solution to generate sequential build numbers, try the Build Number Generator<\/a>. You can also use the
GITHUB_RUN_ID<\/code> but that cannot be customized<\/li>\n\n\n\n- Check out the ClickUp GitHub app<\/a> to see branches, commits, and GitHub status right in your ClickUp tasks. Use ClickUp Automations<\/a> or ClickUp’s public API<\/a> for advanced automations<\/li>\n<\/ul>\n\n\n\n\n\n
Summary \ud83c\udf69<\/h2>\n\n\n\n
Building your CI is a fun process. It’s easy to get started and you can evolve it as you go. Our CI lives after one of ClickUp’s Core Values<\/a>: Progress towards perfection<\/strong>. We’re constantly working on CI improvements for our QA and engineering teams.<\/p>\n\n\n\n
The combination of ClickUp, GitHub Actions, and Fastlane is very powerful and allows building a flexible and fully automated CI\/CD pipeline in less than an hour. Give it a try!<\/p>\n\n\n\n
- If you are looking for an easy and maintainable solution to generate sequential build numbers, try the Build Number Generator<\/a>. You can also use the
- build_app<\/a> to build iOS and Android apps<\/li>\n\n\n\n
- PR workflow \ud83d\udcdc<\/a><\/li>