The configuration manager has to deal with issues that are widely known. Often, we find that a compilation went wrong because of a change, or we want to know how to avoid breaking unit tests. Continuous Integration (CI) and Continuous Delivery (CD) are practices that help organize and manage processes in order to solve and even avoid errors.
Leveraging Teamwork with Bitrise
It wasn’t the first time we invited the guys from Android Devs to our offices. This second time, it was Javier Marsicano who came to talk, beginning with the following question: “Two devs can develop a screen in four weeks. If we have four devs, could they get it done in half the time?”
The unequivocal answer was “No”. “Unfortunately, the management leadership believes it’s possible. But even if it weren’t, it would be good to try and get closer to that point, coordinate processes and teamwork and boost each other’s abilities.”
Bitrise, a tool specifically designed for mobile development, provides an automated solution for implementing CI and CD in mobile apps.
Continuous Integration and Continuous Delivery: An Introduction
Capability Maturity Model Integration (CMMI) is the discipline for managing the evolution of complex software systems. It assesses, coordinates, approves and implements changes in artifacts used to create and maintain software systems. It covers most of the configuration management, except one aspect.
As we can observe, the changes made and released from the configuration management system are automatically controlled and monitored. This is of great importance in Agile environments, given the need to make frequent changes and builds, the diversity of work teams and the search for quick deliveries to add value to customers. In that way, stakeholders get automatically alerted on items to verify or decisions to make based on the requested changes. That’s essential for establishing and maintaining the product’s integrity.
CI is the practice of integrating every version of the work several times a day in a shared way, so as to detect errors sooner.
CD comprises more: it’s an approach to software engineering that enables teams to build software in shorter cycles, guaranteeing that they can be deployed at any time. It seeks to enable faster and more frequent software building, testing and releasing. Thanks to it, you should be able to finish something and deliver it immediately, with a high level of automation.
As we were saying, Bitrise helps implement CI and CD practices. It provides a variety of integration options and out-of-the-box plugins to perform magic (Javi’s words) in Android projects and mobile in general —iOS and Flutter too.
a. Workflows in Bitrise
Bitrise manages workflows: execution flows of tasks and steps. It only gets a step to fail for the whole execution workflow to fail as well. It’s necessary to have a communicating step, for example, a Slack channel on which Bitrise can post.
It can happen that it won’t compile, that it may break unit tests or even that a pull request fails, as in the following example:
When the development or master workflow appears in red, it’s quite serious. While in red, another issue can appear, which will be harder to track and solve.
Bitrise has a number of default steps (which can be modified).
b. Triggers in Bitrise
When you don’t want to be repeatedly clicking on a workflow and don’t want interruptions while coding, you can use triggers, by which you can define which steps will run when certain conditions are met. There are different types of triggers:
- Push triggers: each time a given branch is pushed, a workflow is executed.
- Pull request triggers: they run automatically each time someone opens or creates a pull request aiming at a certain branch.
- Tags triggers: they are used, among other things, to create a tag in Git in order to identify or group commits, or to highlight releases. Such tags are also useful for automatically running triggers, usually for releases.
To configure Bitrise we use webhooks, mechanisms to link Github to Bitrise. “They are URLs provided by this tool which, once configured, allow you to select the type of triggers to use,” explains Javier.
The meetup ended with a live demo on how to set up the initial configuration and how to implement unit tests and build & deploy triggers.
A Few Tips & Knacks
- Have the latest available version of the steps.
- Check that nothing has been mistyped.
- Make sure that everything always appears in green. If something appears in red, it has to be fixed as soon as possible.
- Go’s source code is available in case there are doubts regarding the steps.
- Every step should have access to environment variables, otherwise, they get biased. Everything has to be centralized.
- Run locally first and then run the code in Bitrise.
- Auto-scale the version.
- In order to solve an “Out of Memory Exception” error, set a parameter, a line in Bitrise.
- Optimize workflows and Gradle (for example, functional tests for each PR). Set atomic steps, no more than one thing.
We thank the Android Devs team for coming and we invite you to share your experience with us. Has any of you used Bitrise? What can you tell us about it?