Continuous Integration

Continuous Integration (CI) — is the process of automating the build every time a team member commits changes to version control.

Usually build is followed up with static code analysis tools checks, tests and finally uploading .apk file to some distribution platform like crashlytics beta.

Continuous Integration helps you to:

Ensure code compiles and .apk file is generated

Run static code analysis tools to checks errors in code

Run tests to ensure your code works correctly (not always true :)

Distribute .apk file

There are plenty of continuous integration platforms, some you can set up on your own machine while the other offer cloud-based solution.

As an example we will speak about github and bitrise.io cloud-based continuous integration because it’s simple, focused on mobile and has a lot of integrations.

Note: integrations are very useful, for example you can send message to Slack when build was successful or failed with error.

Setup

After creating account on bitrise.io and adding your github project there are two important things to do:

Add webhooks

Protect branches

Webhooks allow external services to be notified when certain events happen within your repository. (push, pull-request, etc.)

In our case bitrise.io needs to launch build when push or pull-request is performed.

If you have your github account connected to your bitrise.io account then bitrise.io can add webhooks for you automatically; there’s an option for this as the last step of the repo/project registration (on the Add New App page).

If you want to add webhooks manually open bitrise.io project, click on Code tab and copy webhook url.

Next open github project, click on Settings tab, select Webhooks category and click on Add webhook. Paste bitrise.io webhook url and optionally switch to Send me everything event. Finally click Add webhook button.

Protect branches to disable force pushing, prevent branches from being deleted, and optionally require status checks before merging.

To protect branch open github project, click on Settings tab, select Branches category and select branch which you want to protect.

Status checks help to prevent merging pull request before bitrise.io build is finished. Below you can see example of github pull requests window.

Status check in progress

Status check failed

Status check completed successful

Build

Every bitrise.io build has following lifecycle:

Build Triggered

Workflow is Executed

App Ready

Trigger defines “when” and “what” to build. To edit triggers open bitrise.io project, click on Workflow tab and select Triggers.

Below you can see example of trigger which will launch workflow called prod whenever pull request from dev to prod branch is sent.

Workflow defines the steps of a build process. You can customize it the way you want to suite your build process. To edit workflow open bitrise.io project, click on Workflow tab. Here you can create new workflow or edit current.

Below you can see example of workflow which will:

Clone project repository

Launch gradle task assembleProdRelease to generate .apk

Launch gradle task lintProdRelease to check if there are no lint issues

Launch gradle task pmd to check if there are no pmd issues

Launch gradle task findbugs to check if there are no findbugs issues

Deploy .apk file to bitrise.io for distribution

Read more about Static Code Analysis Tools

Workflow editor

When build is finished you will see detail information about build status, time, duration, logs and generated artifacts.

Build detail

You will also get public link where you can download .apk file.

In case if something goes wrong you can check build logs.

More details about Android + bitrise.io