Setup Continuous Integration / Delivery with Bitrise

[This post is NOT sponsored, I just like the service.]

Bitrise provides Continuous Integration and Continuous Deployment for iOS and Android applications. For each trigger that you select (for example after each new new commit) Bitrise will build the app, run the test suite and notify you of problems in case of any failure. In case of success it can also automatically release a new build to the store (or to any beta tester) if you so choose.

We will look on how to set it up for an iOS application. The process for Android is fairly similar. Before that we are going to go through each tab in the web console and see how you can use it.

Website Sections

• Workflow

The workflow defines the action that will be taken by Bitrise each time a new build is requested (by pushing a specific branch, opening a pull request of whatever is defined in the Triggers section). The basic actions are already configured for you, but if you need a custom aciton you will need to add it to the queue. For example in our project we are using swiftgen to generate some Swift files automatically so we added a new script to generate the files after running the Cocoapod installation step.

• Code Signing

For iOS here you can add the certificates and provisioning profiles if you want to set up code signing manually or use an apple account to set it up automatically. For Android you can set up your keystore file, alias and password.

• Secrets

Here you can add Environemnt Variables that are secretly saved by Bitrise that will be kept private. They will be saved securely and used by Bitrise, you can edit them freely, but not see them again even if you’re logged in.

• Environemnt Variables

Here you can add environemnt variables that are publicly exposed.

• Triggers

Each trigger defines a condition to trigger Bitrise. Conditions can be of 3 kinds:

1. Pushing a new commit to a specific branch (or any branch)
2. Opening a pull request targeting a specific branch (or any bramnch)
3. Pushing a new git tag

By default Bitrise will trigger for each new commit and pull request, but you can customize this behaviour.

You are not forced to use triggers if you don’t want to. You can also trigger a build manually or schedule one in the build section.

• Stack

Here you can define which version of the OS and development tools (Xcode for iOS, Android Studio for Android) will be used for the CI/CD build. Bitrise is pretty quick in updating them once a new version is available.

• Bitrise.yml

This is the generated configuration file with everything you have set up in the previous screens. You can also edit this file directly if you prefer. You can also download this file and later upload it for a different application if you want to save and reuse most of the configuration. Usually the steps to build an application are similar so we tend to keep one file for each platform as a base that we can later tweak for each specific application.

• Add the webhook

A webhook will enable the automation features of Bitrise so you don’t have to start each build manually, but Bitrise gets notified of changes (push, pull requests, tags,..) by your git provider. You can set it up from the code section -> webhook set-up area.

Bitrise can set it up automatically, or it can be setup manually, by pasting the provided bitrise webhook url inside the appropriate section on Github, Gitlab or Bitbucket. The automatic set up doesn’t always work so if you receive an error you will be forced to proceed manually.

The process is pretty straightfoward: copy the Bitrise link and paste it in the relevant section on your Git host service.

For Gitlab go to Settings -> Web Hooks -> add the url to the URL field and select the events you want to ping the webhook with. For Bitbucket go to Settings -> Webhooks -> Create Webhook -> add the url to the URL field For Github go to Settings -> Webhook -> Add webhook -> add the url inside the payload section of the URL field

Platform Specific Workflow

Most of the shared setup is explained in the “Website Section”, the platform specific sections will mostly cover the workflow section.

What follows are the steps to build a specific application, what you may need will be slightly different. You may need to add or remove one or multiple steps, but this provides a good starting point.

iOS Application Setup

• Activate SSH key This will enable SSH access to be able to clone the repository.
• Git clone repository Clones the remote repository to Bitrise.
• Bitrise cache pull If there is something in the cache this will speed up the build process.
• Certificate and profile installer Sets up the certificates and provisioning profile that we uploaded to be used in the build process.
• Cocoapods install Downloads and installs the dependecies required by the application.
• Run script For this project we are using swiftgen to generate swift code to securely access resources and colors at runtime. You can use this step to run any custom script or remove it entirely.

Be mindful that the filesystem on the VM is different so if you want to access the project directory you’d need to access /Users/vagrant/git/ instead.

• Xcode archive and export Builds the application.
• Deploy to bitrise.io Makes the generated application available to download directly from Bitrise web interface.
• Cache push Updates the build cache to speed up subsequent builds.

Android Application Setup

• Activate SSH key This will enable SSH access to be able to clone the repository.
• Git clone repository Clones the remote repository to Bitrise.
• Bitrise cache pull If there is something in the cache this will speed up the build process.
• Run script We run a custom script to set up various environment variables for accessing the keystore file.
• Install missing android sdk Install whatver SDK we need in order to run the application.
• Run Android unit test We run the unit test suite and only if successful we proceed to the next step.
• Deploy to bitrise.io Makes the generated application available to download directly from Bitrise web interface.
• Cache push Updates the build cache to speed up subsequent builds.

As you can see most of the process is shared between the two apps.

Conclusion

While we are not using Bitrise for Continuous Deployment we can be confident that each time we push a new commit or open a pull request the app will build and pass all tests so anybody can clone the branch without worries.

Even if all your deployments still happen manually you can also take advantage of the generated application bundle / ipa to upload to the various stores without having to generate it again manually.

Source: Webhooks setup