Mobile Continuous Integration and Delivery (CI & CD)

Push fast, push often — moving testing upfront in the development cycle

By Ishaan Bhatnagar and Astha Sharma, Program and Release Team, Hike

Earlier this year, Kavin Bharti Mittal (our Founder and CEO) decided it was time to re-tool our systems and re-build our culture. He asked one big loaded question to the teams:

“How do we supercharge the productivity of our teams so that they can move incredibly fast, take high-quality decisions, to build experiences that our users will absolutely love?”

There’s a tremendous amount of work happening across the company to further this idea and today in this blogpost, we’re excited to talk about the incredible progress our Release Engineering and Tools team has made on Mobile CI (Continuous Integration) and CD (Continuous Delivery).

Our Goal

Our aim is to bring testing upfront in development cycle so that every piece of code gets a road test before it is merged. CI and CD work in tandem to make sure the software is always ready for production, and reduces the need for human intervention, thereby, cutting down on delays and errors.

What is CI or Continuous Integration?

CI is the process of automatically detecting, pulling changes, building and testing to:

• make sure that the code pushed to our repository is “robust” and suitable for further use in the codebase
• systematically merge code into the codebase
• ensure quality standards of the pushed code are upto the mark with quality pre-checks
• prevent unwanted or non-tested (unit) code from being pushed into the codebase

Why Do We Need It?

• To ensure that no rogue code is merged into the codebase which leads to—longer Test cycles and longer Release cycles
• Increase in risk of bug leakage to Beta or Production users
• For development discipline
• Make each developer accountable for his code and through checks help the developer gain confidence in the code
• To ensure “fail fast” policy i.e. failures and bugs can be detected upstream.
• Keep the code base always ready for an alpha release and open to receive alpha feedback as early as possible in the release cycle
• For timely releases
• To minimize human error
• To remove friction across teams by standardising the process.

What We Did

We created a standard automated flow across the organisation for both Android and iOS platforms. The way this works is:

Whenever code is pushed from a developer’s feature branch into our release branches, it goes through our standard quality check process. Our system detects the raised Pull Request (PR) and fetches the latest code along with checking for associated JIRA ID.

For this we established a robust CI system where multiple checkpoints run concurrently.

We build different build flavours of Hike to ensure we’ve covered all the chip architectures and devices our app supports.

While the builds are being compiled, we run Static Code Analysis which includes lint, PMD etc. These help catch null pointer exceptions, resource and memory leaks, unused variables, and risky system calls. Along with this we also execute checkstyle to ensure Hike coding conventions are respected and parallely execute the XML/JSON validation.

Another concurrent system has the responsibility to execute unit tests to ensure code quality while functional tests (XCUI Tests for iOS) are executed in parallel to ensure robust regression testing.

Lastly, we ensure the application size is within the set benchmark.

What Do We Mean by Continuous Delivery?

Continuous Delivery (CD) is a further extension of CI where the goal is to:

• Ensure continuous delivery of code to alpha/beta environment with
• Validation checks (UAT, Regression, Sanity etc.)
• Versioning/tagging
• Post delivery (or release) monitoring and communication across the organisation

Why Do We Need It?

At Hike, we need to push releases continuously to cater to user requests as well as introduce new features in-app. So we need to ensure

• Deliveries meet the criteria for high quality and robustness
• Daily Alpha builds to get feedback (essentially dogfooding)
• Each delivery is tagged with the release version
• Post delivery we are able to closely monitor the release metrics and user sentiments in automated fashion.
• Communicate the delivery performance (success or failure) across the organisation

What We Did

Since we wanted to simplify and automate stuff to prevent human error and intervention, we created a standard automated flow across the organization for both Android and iOS platforms.

We start with an automated cutting-off of a temporary branch from our release branch. We again build different build flavours of our app to ensure we’ve covered all the chip architectures and devices our app supports along with a test app (for iOS we use enterprise flavour).

During cut-off we ensure that our CD system takes care of updating the versions (Semantic versioning) of the app automatically.

Post that, the builds with different flavours go through a Functional Test cycle.Concurrently the build is passed to a Performance Testing Suite where we measure each identified performance impacting action against the established benchmarks.

The build is then uploaded to Play Store/App Store (via Fastlane for iOS) and further distributed to our Alpha user base who are then notified via slack/email.

For Production deployment; being a client app we need to reduce risk and hence, we have a provision for “Manual Sign Off” from various stakeholders such as Product, Design, UX, UAT, Analytics etc. The time for sign off may vary as per the complexity of the deliverable.

Lastly, each deployed build is tagged on GitHub with app version and “Release notes” added to the comment section of the Git tag.

Tools

It is important to select tools which are low maintenance, scalable, reliable and flexible so we selected:

1) Jenkins

Jenkins is a self-contained Java-based program, ready to run out-of-the-box, with packages for Windows, Mac OS X and other Unix-like operating systems.

As an extensible automation server, Jenkins can be used as a simple CI server or turned into the continuous delivery hub for any project.

2) Circle CI

CircleCI’s continuous integration and delivery platform makes it easy for teams of all sizes to rapidly build and release quality software at scale.

3) Fastlane

Fastlane for iOS to automate tedious tasks like generating screenshots, dealing with provisioning profiles, deploying builds on iTunes/TestFlight etc.

Outcome

Through CI and CD we were able to:

1. Create an automated system with standard guidelines across the organisation.
2. Eliminate basic or fundamental code errors such as null checks, invalid JSON, wrong app versioning, etc. which could easily be overlooked by the reviewer or even the author of the PR using static code analysis.
3. Remove human intervention for integration and delivery thereby supercharging the productivity of the developers and allowing them to stay focused.
4. Reduce time, effort, chase ups and manual communication
5. Release cycle was reduced by 50%
6. Push multiple alpha builds into the hands of alpha users to gain valuable feedback upstream before even going to the Beta base or Production so:
7. Our Product team can absorb Product feedback at early stage of the release cycle
8. Enable analytics, design and performance feedback upstream.

At Hike, effective implementation of Mobile CI and CD has made it possible for timely releases with the required quality. An added advantage for us is that the system is scalable and generic in nature while staying low in maintenance effort.

The wonderful results we have seen so far make us want more and are aiming to reach a point where we can do upto 6–12 alphas in a day and each release is a BETA candidate in terms of quality.

We want to remove any (and every) possible dependency on CI-CD so that Developers, Testers and anyone else involved can just focus on contribution to the organisation, while the CI and CD handle themselves. More about this soon 😊