Continuous Delivery of Android with CircleCI 3: Workflows and Flavors
In Part 1, I explained how to get your CircleCI setup to automatically publish to Google Play. In Part 2, I explained how to make sure the right branch deploys to the right track. In this post, I explain how to make sure different flavors deploy and build correctly. We’ll be going through an implementation of setting up different workflows in your config.yml file, and then setting a different deployment based upon the branch.
The first thing we need to do is to split up our build, tests, and deploy tasks into different jobs and then we can assign those jobs to run in our workflow section. The config.yml file below shows an example of these jobs.
Now that you have these 3 jobs, you can create a workflow section just below the jobs in your config.yml file. You want the build and tests jobs to run on every commit, but you want the deploy job to run only on your master, release and develop branches. To do this, we just add a filter to the jobs, like so:
You’ll likely notice that each step requires the previous steps. This is to make sure that each next job only starts once the previous one finishes. If your jobs can run independently (such as unit_tests and instrumented_tests) then you can set them up to run in parallel if you want.
The important part is that the deploy job contains filters so that the deploy job only runs on branches that you specify. You can also match branches with regex, so that for example all branches that start with “release_candidate/*” deploy.
The end result of the above config.yml is that Pull Requests and rogue commits on feature branches will not deploy, until they are successfully merged into either develop, release or master branches. If all goes well, your CircleCI Workflows page’s latest build should look something like this:
But now you want to specify your CI to deploy your develop/release branch’s staging flavor, and your master branch’s production flavor. This can be done with just a few adjustments to the config.yml file we already have.
First, replace the deploy job with a deploy_staging job, which has publishStagingRelease as its task. Then run that task on the develop branch, like so:
If you have a different flavor name you need to specify the correct gradle publishing task to run based on your specific configuration.
Here is a Pull Request that contains all of the changes I described in this post.
Every time you are manually building something that could be automated, you’re wasting time. You should learn to configure an ideal CI system for each of your projects. DevOps is essential, and if you don’t have a DevOps team, you need to become your own DevOps team.