Saving Time Using Bitrise Workflows in Your Android Projects

Ship apps faster with this CI/CD tool

Photo by Djim Loic — Unsplash

Time is a very precious resource in software development ⌛️. Repetitive tasks such as running unit tests 🧪, generating builds 📦, or releasing to some users 🏁 can be bottlenecks when the developer makes them manually.

The main idea of this article is to show an overview of how you can save time using Bitrise in your Android Projects.

Starting point

There is no cake recipe, but I think a good starting point is answering the following questions:

• What is the versioning system used in my project?
• Are there Pull Requests (PRs) in my workflow? Is there someone reviewing my code?
• Is there a base branch?
• Who needs to access the releases to make tests?
• Is the app published?
• Is there a task board or a ticket system where I need to update the progress of a task or bug?
• Do I have unit tests to run? What is the frequency I need to run these tests?
• Do I have a credentials file, such as keys or tokens required to run the app?

Creating Workflows on the Bitrise

Bitrise is a mobile CI/CD (Continuous Integration and Continuous Delivery) platform where it is possible to create automated Workflows. So if you have the answers to the previous questions, now it is time to create Bitrise Workflows to help your needs.

I will show two manual processes of a personal project that I converted to be Bitrise Workflows.

Opening a PR

Starting by opening a PR, if it is approved, I need to run all unit tests. After that, I send a build to the Firebase App Distribution, where specific users will test the modifications before merging. The following diagram shows how the manual process works:

Manual Process 1 — Opening a PR

In this manual process, it is a good study case to check the tools:

• GitLab: where the repository lives;
• Firebase App Distribution: where the builds are released.

The main task to fully automate this manual process is to “teach” Bitrise how to:

• clone the repository;
• monitor the repository each time the developer opens a PR;
• generate the build artifact;
• distribute the build artifact in the Firebase App Distribution.

To create a project in Bitrise, you need to specify the Git URL pointing to your repository. You have to define your project as an Android project. After that, you probably have a Workflow template.

In your Workflow template, you need to define a trigger. What is when the Workflow should start. For that, Bitrise uses Webhooks to run an extra logic in the Gitlab server (or GitHub, Bitbucket, they are all working on a similar way). I have an image showing a trigger defined for each PR from any branch (feature branchs) to the base branch (main).

Defining a Trigger — Workflow PR

Each time you open a PR, the workflow should run in the Bitrise server.

Workflow PR

Each time a Workflow starts, Bitrise has to access the repository. You need to set an SSH key for that. Don’t worry! You need to do that one time.

Another great tool is the Test Reports. After the execution of tests, Bitrise generates a report:

Test Reports — Bitrise example.

To distribute your app using Firebase App Distribution, you need to add a new step in your Workflow. Bitrise provides a library of steps. There, you can find steps to improve your Workflow according to your needs.

Adding a new step for Firebase.

For example, if you have to update a JIRA ticket, you can look for a step to handle that. Sometimes you have more than one option:

Another Example of steps — Updating a JIRA ticket

Workflow PR is helping me to run all my unit tests each time I open a PR. I also defined a trigger when a new commit occurs to the PR already opened.

Release Version

The difference between the manual process Release Version and the manual process Opening a PR are the tasks:

• increment the version;
• don’t run the unit tests;
• send the build to the beta channel in Google Play.

Manual Process 2 — Release Version

First of all, we need to define the trigger. Each time I commit a change in the main branch (closing a PR) is a good option.

Defining a Trigger — Workflow primary

We can increment the version using the following step:

Step to change the versionCode and the versionName.

This step has two output variables: ANDROID_VERSION_NAME and ANDROID_VERSION_CODE. You can adapt the build.gradle to catch these values during the build time in Bitrise.

Code sample using the environment variables provided by Step.

Bitrise has a step to send the build to the Google Play:

Google Play Deploy

In this step, it is also possible to define the track where the application will be made available. In my case, I am making it available in the “beta” track. It is essential in this step that you create a service account on Google Cloud. After that, you will have a JSON file that will allow Bitrise to use this account to send builds to Google Play.

Last but not least…

You have a place in Bitrise to create environment variables and secret variables:

Secret variables example.

These variables are sensitive, so it’s nice to have them defined in your local environment (ignored by Git) and in the Bitrise. So, you can use both according to the environment that is generating your build.

You can also provide the variables as resources:

Conclusion

Automating time-consuming tasks can be a challenge at first, but after the initial effort to configure the Workflow, you will see the time spent at the beginning will be recovered quickly.

The idea of this article was just to give an overview. If you are interested in a specific step, feel free to comment. I am happy to help with links and reference materials.

Thanks!