Android CI/CD pipeline with Bitrise: Deploy your apps to Google Play Store
By: Caner Gulgec
Tags: Continuous Integration, Android, Engineering, Continuous Deployment, Bitrise

In the mobile app industry, Continuous Integration(CI) and Continuous Deployment(CD) play an important role in terms of letting teams to deliver code changes frequently, safely, and automatically. Today, there are lots of different CI/CD tools like Jenkins, CircleCI, AppCircle and etc, but in this post, we will be talking about Bitrise.

Before I deep dive into the topic let me explain what CI/CD is and why we really need it.

What is Continuous Integration?

It is a software development practice that checks if the codes are acceptable for integration. CI workflow may include operations like app compilation, static code reviews and unit/UI testing with automated tools.

What is Continuous Deployment?

A continuous process which deploys codes to production system for every change that passes automated tests successfully.

Why should we use CI/CD?

If you are working with a team, you should be familiar with the development process. Each team member opens pull requests and merges their codes in a continuous cycle. In most cases, the master branch should be the most stable one and ready for production when merging codes to it. However, how can we make sure that it is fully reliable and tested properly?

That’s the part where CI plays an essential role. For each code integration, it runs an automated build in the background and checks whether tests are successful or not. The advantage of using CI in the project is that developers can fix potential bugs as soon as possible.

In addition, the importance of using CD in the project enables the team to work more efficiently and increases the quality of the whole development process.

Setting up Bitrise

The first thing to do is to open bitrise.io and create a new Bitrise project. This will only take 2– 3 minutes because Bitrise really simplifies this process for you.

After connecting your repository, Bitrise adds an SSH key into your repository automatically as a deploy key (This can be done manually if you have private dependencies). When the configuration is completed, Bitrise will ask you to register a webhook in your repository. This is really important because when you register a webhook, any code change in the repository will trigger the primary workflow.

That’s it :) If the validation is successful, Bitrise will give you the default workflow based on the project configuration.

Setup Google Play Project

First, you need to deploy the first APK or AAB manually to Play Store.

Secondly, open API ACCESS page in Play Store and link your API project by clicking “Create new project”

Then, click on Create new service account. This will redirect you to Google Api Console

After completing service account details, don’t forget to create a private key (JSON file) and download it. We will use it later on.

Now the last step is to grant access to the service account on Play Store. After that, we will have completed Play Store part of the deploying process.

Let’s open bitrise.io

After login with your account, select the project that you want to deploy and click on Workflow Editor.

The next step is to click on Code Signing tab. After uploading keystore file and keystore credentials, we need to upload the service account JSON key which we downloaded before.

In Bitrise, we have two workflows. Primary and Deploy . Just to clarify, both of them are created automatically when you add your app. They have almost the same steps and basically what they do is to activate the SSH keys, clone the Git repository, deploy build artifacts, and handle caching. Deploy workflow has extra steps for building the project and if the build is successful it deploys it to Play Store or any other market. For this tutorial, we will be only interested in deploying app to Play Store.

and . Just to clarify, both of them are created automatically when you add your app. They have almost the same steps and basically what they do is to activate the SSH keys, clone the Git repository, deploy build artifacts, and handle caching. Deploy workflow has extra steps for building the project and if the build is successful it deploys it to Play Store or any other market. For this tutorial, we will be only interested in deploying app to Play Store. In deploy workflow, click on Android Build step. This step actually is similar to the primary workflow except for one thing. As we are planning to deploy it, we need to choose release variant. Build type is up to you. Choose apk or aab.

Next, click on Android Sign step. Bitrise generated env variables for us in the Code Signing tab when we provide our keystore credentials, so we can use them all for filling the required fields. If you are uploading apk, then you can use $BITRISE_APK_PATH. For aab it is $BITRISE_AAB_PATH. One final thing to mention is that, If your app targetSdk is 30, then you need to enable apksigner and choose v2 for APK Signature Scheme

We are really close to the ending! For the last step, you need to add Deploy to Google Play step to the end of the Workflow. Add your service account JSON key file path, app package name, and apk or aab file path to the required fields. For the track field, you need to choose where you want to deploy your app (internal, alpha, beta, production, or any custom track). That’s it! Your app is ready to auto-deploy.

One more thing that I need to mention is when we need to trigger deploy workflow and how. Let me introduce you to Triggers. Go back to Workflow Editor and click on Triggers. For my case, I need to trigger deploy editor when somebody pushes codes to master branch. You can add as many triggers as you want. Also, for every pull request, I wanted the primary workflow editor to be triggered so that we can verify if something needs to be fixed before merging it. By the way, for every build, Bitrise notifies you via mail or slack about build status.

Bitrise really makes developers’ life easier even if you do not have any experience with CI/CD before. We did all the processes with Bitrise visual editor without writing a single line of code or something :)

CI/CD at Armut🍐

We were using CircleCI at Armut for a couple of years. However, we migrated our applications successfully to Bitrise recently. There are two reasons which make us choose Bitrise over CircleCI.

Ease of use : Bitrise workflow editor provides us very simple and pleasing user interface. The best part of this tool is, we don’t have to struggle with .yml files.

: Bitrise workflow editor provides us very simple and pleasing user interface. The best part of this tool is, we don’t have to struggle with .yml files. Out of memory(OOM): CircleCI container started to throw OOM exception for each build lately. We tried many solutions like increasing container default size and Java heap size. However, we could not overcome the build error.

By the way, if you are curious about how CI/CD was implemented at Armut before, you better check this post.

Happy Coding!