How to implement mobile continuous integration(CI) and delivery(CD) using bitrise.io

If you got here, I’m going to assume that you already know what continuous integration(CI) and continuous delivery(CD) means. But if you do not know, no problem, I will indicate two links, one from Martin Fowler and another from Jez Humble, the main references in the world to talk about these pratices: Continuous Integration , Continuous Delivery. I also point out the book Continuous Delivery, by authors Jez Humble and Dave Farley.

Anyone who develops mobile applications and manages the publishing and release of new versions certainly knows the manual effort to test, sign, change version and send new builds to the App Store and the Google Play Store, especially if you generate multiple builds per day . At some point, sooner or later, you will ask a very common question: “How to automate?”.

Luckily, there are currently some options, one of these options could be implemented using Jenkins + Fastlane. As you got here and you already know what CI & CD means, you probably already know or have heard of Jenkins, the butler responsible for building, testing, and releasing your new software versions while you’re having coffee, besides of performe other requests. Fastlane is an incredible tool for automating many common "repetitive and annoying" tasks in the mobile process of developing and releasing, created by Felix Krause, it was acquired by Twitter in 2015 and joined to the suite of mobile development tools called Fabric , which was recently acquired by Google. To use Jenkins + Fastlane has the advantage of greater freedom and control for time, who would be using open source tools, that can be configured and deployed out of the box on own servers, however it has disadvantages the cost to keep these Mac OS X servers with Xcode to be able to perform builds for iOS.

After much searching, I ended up finding Bitrise — bitrise.io(this is my referral link, but if not want to use it, no problemas use this link), a Hungarian startup that is developing an incredible tool to implement CI & CD for mobile applications. I decided to test and simply became an absolute fan of the platform, mainly due to its simplicity (a beautiful work of UI / UX) and its quick support, in fact, I would like to make an addendum to thank Viktor Benei, CTO Bitrise, for some Sometimes I needed to ask some technical and commercial questions and I was quickly answered by him. With the bitrise our pipeline of Continuous Integration and Continuous Delivery was as follows:

But anyway, let’s go to what matters, how does Bitrise work? How to start?

Create application and give access to code repository

Starting with Bitrise is relatively simple. First you need to create an application on your Bitrise dashboard and give access to your code repository. You can do this by connecting your Github / Bitbucket / Gitlab account, in which case you will give access to all your repositories. However you can also add a repository manually, in which case you need to add the Bitrise public key in your repository, you can add this key in your repository settings (Deploy Keys repository settings on Github or Access Key in your repository settings on Bitbucket).

Specify a branch for scan validation

After choose the branch for scanning, this branch will be used to validate your project and detect the best build configuration.

Project Build configuration

In the next step, a scan will be performed on your project to identify the best settings for stack (machines configurations) and steps templates that will be used to build your project.

The project used in this article was developed in Ionic, below we can see that it was correctly detected by Bitrise:

But if your settings are not detected correctly or are not detected, you can try to choose manually, based on some of templates below.

If none of templates above are compatible with your project, you can try to manually choose your stack and then you have to set up your steps from scratch:

Webhooks

The last configuration is from Webhook. In general this step is ignored by quickstart itself, but you can and should enable this option in your project settings if you want to use the triggers. See in this link how to enable webhooks in your project settings.

When you finish the quickstart, if your project settings were detected correctly, you will already be able to perform clone, install all dependencies and compile your project.

Workflow Editor

I will now talk about the Workflow Editor, where you configure the steps to compile / test and deploy to the stores (App Store, Google Play Store, etc.). In the Workflow Editor you can also add your certificates / provisioning profiles (iOS) and keystores (Android), create Environment Variables and Secrets, as well as configure Triggers. Oh! The Workflow Editor, like most Bitrise tools is Open Source, if you wish to contribute or to know more information click here.

Workflow Steps

To add a new step just click on the “+” icon in the left column of Workflow, at the position of the flow you want, there are dozens of steps created by the team bitrise and community, they are divided into categories (Test, Deploy , Notification, etc.). You can also create and publish your own step, click here to find out how. In addition, steps can be changed in the flow by Drag & Drop way. You can also create multiple Workflows in the same project, for example a Test Workflow that will run when there is a Pull Request and a Deploy Workflow that will run when a Push occurs, you can define this in your Triggers. The default Workflow is called “Primary”, to create a new Workflow simply click on “+ Workflow”.

Code Signing

For you to publish your app on the Google Play Store (Android) and App Store (iOS) you need to sign your app. To learn more about signing Android and iOS apps, I’ll to indicate two links: Signing Android app, Signing iOS app. But anyway, to sign your app you need certificates and provisioning profiles (iOS) and Keystore (Android), in this section that you must upload the signature files that will be used by the steps that will be responsible for signing your application.

Tip: To collect the required signature files for the iOS platform, you can use codesigndoc, a very useful tool created by the Bitrise team.

Security Alert: Here is a security issue that should be considered by your team, as you will be “sharing” your signature files with Bitrise, which means that if these files are leaked for some reason they may compromise the security of your app. In this case, it is important that your team take steps to learn more details about the security procedures adopted by the Bitrise team. I reinforced that I felt safe in relation to such procedures and currently the applications that I develop are signed and sent to store directly by the Bitrise.

Secrets

In this section you can add secrets, which are variables you do not want to leave exposed in the build configuration file (bitrise.yml). Ex: User and passwords, tokens, etc. Learn more about secrets clicking here.

Env Vars

In this section you can add Environment Variables that will be used in your steps, these variables are exposed in the build configuration file (bitrise.yml). Ex: Paths, Workspace, etc.

Triggers

As mentioned earlier you can also define Triggers, which are run when there are changes in their branchs, in PUSH, PULL REQUEST, TAGS events. So in this section you can execute a Workflow every time changes occur in the defined branch, for this to works your webhook must be configured. To learn more about Bitrise triggers, click here.

Build Configuration File & Bitrise CLI

Finally I would like to talk about the Build Configuration File, a YAML file that defines all your steps, when you edit your steps using the graphical tool your configuration file changes. In this section you can edit your steps using code, very useful when you want to replicate a configuration that you have already done in another project. In addition, you can test and edit and configure your builds locally, in the same way that they will run in Bitrise, just download Bitrise CLI.

Conclusion

While agile development has brought business development teams together, reducing gaps between these areas, DevOps brings agility to deliverings by reducing gaps between development and operations. Nowadays, agile development means adopting best practices so that your team is more focused on the business / customer and delivering increasingly short and continuous deliveries, making them easier to test. And it should be no different in Mobile development, in this way Bitrise brings an incredible platform to help developers / teams / companies in this process with a sensational UI / UX work, with several integration options, which makes it absurdly simple to fit in any pipeline and start applying the best practices of CI & CD. Well, in other words, as Jez Humble himself replied in one of his twitters: If you are averse to risks, continuous delivery helps you to minimize them.