Android Continuous Integration

Imagine that you are working on Android project that has around 17353 Class with total 102439 Method, gradlew assemble will be your worst nightmare! Building APK would be painful, what about you having three flavors to build!

The solution here is Continuous Integration (CI). CI is a powerful tool for the Android team at Opensooq. It gives us a platform to automate the build and make the build self-testing.

To achieve this, we have a dedicated mac mini running our CI. This machine run Gitlab, build APKs, merge code, and send us notifications.

 

Our development cycle is extremely fast, and we’ve built tools to keep it that way. It’s common to write code and have it running on the live site a few days later.

Actually, Generating a build manually can lead to unstable or inconsistent environments making it difficult to deliver good build. Our QA asks for many builds that take time from engineering. So, We can say with CI you can continuously saving time.

After building our CI, the steps to get new build is:

  1. Create Tag
  2. Push the Tag
  3. Receive the builds.

Wow, as simple as that!

Step – Step to get the build from CI :

Our code controlled via GitLab, and we are also using Crashlytics from Fabric for crashes and performance reporting. after searching for the best approach to integrate CI, we found many services that we can use, like:

  1. Jenkins CI
  2. Circle CI
  3. GitLab CI

Each one has it’s own strength and week points.

Since we are already using Gitlab we were able to use some of it’s CI features.

GitLab can cloudily do all the job with few integrations using Docker Image to run the Gradle command then export the APKs to GitLab.

But what we were looking for is to achieve this on a local machine, So we used GitLab Runner from GitLab CI to communicate with the local machine that should have a GitLab Runner installed on it to export the builds.

Opensooq Android Runner


Learn more about GitLab Runner
.

We also decided to manage our beta APKs using Fabric Beta since we already have it integrated with our project, so we used FastLane to automate beta deployments and uploading the APKs to Fabric Beta.

FastLane open source tool lets you configure lanes to support your deployment workflows.

GitLab CI will look for the .gitlab-ci.yml  file to start the job.

.gitlab-ci.yml File can be configured to trigger the job on a specific action happened on the VCS like commit, tag, and merge .. etc. Our .gitlab-ci.yml configured to trigger the job once Tag pushed, it contains tow jobs, one for building the three flavors and another one for building one flavor based on the Tag name regex, for example, if you check the below screenshot, the ‘release_production’ job will be called if the Tag name ends with ‘-QA’ or ‘-Release’ only, while ignoring the branch name.

Opensooq .gitlab-ci.yml File

Our .gitlab-ci.yml File, as shown above, contains three jobs ‘release_production’, ‘release_webmanger’, and ‘release_staging’, each job responsable for one flavor. each job call scripts from FastLane.

You will need to add the FastLane files to your project, there will be a file called  FastFile which contains the script which on our project build the APKs and upload them to Fabric Beta.

Opensooq FastFile

If you check the above screenshot from our FastLane file, you will see the three jobs that called from the .gitlab-ci.yml File, each one run different Gradle command, also each one contains the Crashlytics configurations to upload the exported Beta APK to Fabric Beta, then a notification will be sent to ‘android_ci’ group members on fabric, and email will be sent to the declared emails.

Once everything configured correctly and the job starts running you can check it on GitLab Pipelines.

Opensooq Pipelines.

you can check the details and logs of the job once by clicking on it like below.

Opensooq ‘release_apimanger’ job details

This was a general overview of what we have done with CI in Opensooq Android project.

At this point we have finished the Continuous Integration to automate the APKs generating based on tags, the Continuous Delivery to upload the beat APKs, next steps will be adding the automated releasing (Continuous Deployment ).

 

 

Conclusion
Continuous integration is a powerful tool that requires a lot of love to get working and maintain, but if you’re willing to put in the work, you’ll get a lot out of it. Having a tool that automatically builds your commit, runs static analysis and tests on it, and then merges it into your master branch… do you feel that? Yeah