Setting up an automated system for nightly builds
How we used Jenkins for continuous integration and saved an hour daily for the whole team.
Context and challenge
The tech team has worked in weekly sprints when building the Zomato app for as long as I can remember. Every single day, about six developers on the team waited for a build to be created, uploaded for distribution, and then made available for download. One person merged all of the code. If they missed anything, back-tracking was a painful task. Every week, this manual process cost us over 20 hours of manpower. Pretty crazy huh?
To save time and resources, we needed to streamline this painful process. We needed a continuous integration (CI) system to monitor the newly merged code. It would let us instantly test the app as we are developing it. We could avoid depending on the manual effort of one person to merge, build, and upload the app.
We set up a CI system using Jenkins. This system takes our merged code and continuously creates test builds from it. This is called a continuous integration (CI) system. I introduced this for the Cars team at Gameloft and now was my time to test this approach at Zomato.
How it works
- Jenkins continuously monitors Zomato’s iOS app Github repositories for any changes.
- Whenever there is a change on Github, an attached webhook is triggered by Jenkins running on our CI Server.
- Once a webhook is triggered, Jenkins pulls code from all our iOS repos and starts a Fastlane build script to create a new beta build of the app. (Fastlane is another tool that helps build XCode projects through command line.)
- The completed build is uploaded to a test server and can be downloaded from a URL.
- Finally Jenkins triggers an email to all the preconfigured developers, testers and other stakeholders who need to test the latest beta build of the app.
With Jenkins, we eliminated the hassle of compiling and building a beta app every time big changes were made. Now an automated system handles this routine task. When a build is compiled, any bad commit that breaks the build notifies us immediately with an alert.
At the end of every day, the commits of that day are compiled into a summary of commit messages. It serves as a great EOD report for the team and we know exactly what got merged in the nightly release. Interestingly, it also motivates the team to write descriptive commit messages since the summary is shared to the entire organization.
A CI system is a great practice to avoid manual compilation, handle errors, and automate processes for your development team.
As the iOS team and the app have grown over time, this CI system has become more useful every day in taking up our grunt work. With this in place, we even automate tasks like sending all the new strings for localization and continuously taking screenshots of our main app flows.
It’s been one of the biggest process-oriented features we’ve set up and it saves us a lot of man hours and headache! I aim to have a CI system installed within any of the teams I work with in the future.