Push fast, push often — Deliver app with minimal human intervention
By Rahul Sharma Release-Tools Team, Hike
At Hike, we’re building the Rush Gaming Universe (RGU) where players battle in India’s most popular casual games and use their skills to Play, Compete, Win. With blockchain, we’re entering a new era of gaming, one where players will participate in a new kind of game economy where they are also owners of the networks they help create.
With the vision of the Rush Gaming Universe, Hike team started working on the Rush by Hike app which is an integration of Unity technology with native Android and iOS. Our incredible developers were busy developing the app features while there were these questions:
How can we make sure that bugs and inconsistencies are captured early in the development cycle?
How can we reduce human intervention during the development cycle?
How can we reduce the delivery time of the app?
In this blogpost we are excited to talk about the CI and CD system. Our Release Tools team has developed to bring testing and analysis upfront in the development cycle and to automate application delivery so that every piece of code is well tested before it is merged and there is no delay or errors due to human intervention.
What is CI or Continuous Integration?
CI is the process of automatically compiling, building, analyzing and testing of source code whenever a pull request is raised to:
- Make sure that the code pushed to the repository is well written and does not have any compilation errors.
- Ensure quality standards are followed with the help of quality checks.
- Ensure that no unwanted change is pushed in the repository.
- Ensure that the pushed code passes a sanity test suite before it is merged.
Why Do We Need It?
- To ensure that no rogue code is merged into the codebase which leads to
- longer Test cycles
- longer Release cycles
- increase in risk of bug leakage to Production users
2. To ensure development discipline
- Each developer is accountable for his code and the checks help the developer gain confidence in the code
- Also, to ensure “fail fast” policy i.e. failures and bugs can be detected upstream.
3. To ensure the code base is always ready for release and we can receive internal feedback as early as possible in the release cycle
- This helps us ensure that we deliver timely releases
4. To minimize human errors
5. To remove friction across teams by standardizing the process.
What We Did
We created workflows for Android and iOS repos using CircleCI, so that whenever a PR(Pull Request) is raised the workflow is triggered on CircleCI.
Android CI Workflow
Once the PR is raised, the CircleCI workflow is created and it waits for manual approval. After the approval various checks are executed,
- JIRA check ensures that every PR’s title contains a valid JIRA ID.
- Checkout code steps creates the merged code base for further checks to run.
- Danger check makes sure that the code in the PR follows a set of predefined rules before it is merged.
- Android lint ensures the code follows Android development rules.
- Config files validation step ensures that no malformed Xml or Json is pushed.
- Size analysis ensures that APK size is not increased by a certain threshold.
- APK Analysis ensures that no unwanted change in the app’s metadata is pushed.
- Espresso tests are also triggered to make sure that the pushed code passes a predefined set of sanity checks.
iOS CI Workflow
iOS Workflow is also created in a similar manner. It begins with a check for whether the PR is raised for one of the main branches or not and then multiple parallel checks are executed on the source code.
- JIRA ID ensures that there is a valid JIRA tracking ID given in the PR title.
- Dev Tested step makes sure that the developer has tested the code on their side and has put a label dev_tested on the PR.
- Compile check ensures that the pushed code compiles.
- Danger check makes sure that the code in the PR follows a set of predefined rules before it is merged.
- Unit Tests check ensures that Unit tests are passed for the pushed code.
- Functional tests written in XCUI Test Framework are also executed on the pushed code on iphone simulators.
Unity Code Integration with Native Code Base
Gaming part of the Rush application is developed in Unity and to create a complete Rush application, we need to merge Unity code to Android and iOS native code.
For this Integration, we have developed a Jenkins pipeline which creates Unity Library files by exporting the Unity project as gradle project for Android and XCode project for iOS. Then we copy these files to the Native app code base and push it back to Native app’s repository.
Image: Unity Integration to Native Code Base
More details about Unity integration process is available here: Automating Unity Mobile Build Systems
What Do We Mean by Continuous Delivery?
Continuous Delivery (CD) is the process of building, testing and making the app delivery-ready for the release candidate code base to:
- Ensure application is ready to be delivered after
- Client side application security is applied.
- Successful execution of Validation checks (UAT, Regression, Sanity etc.)
- Versioning/tagging
Why Do We Need It?
- To ensure that the application is ready for Release after UAT, Regression and Sanity testing.
- To ensure that
- The release ready code is delivered as often as possible.
- The delivery process requires minimal human intervention.
- The delivery process runs in automated fashion, saving human effort and time.
- The application being delivered is secured by client side security.
3. To standardize the tagging and versioning process.
What We Did
We created Jenkins pipelines to create release ready applications, which can be tested and released after release team’s approval.
Android CD Workflow
Android CD Workflow checks out the latest release candidate code base, creates APK and secures it by applying client side security.
- The produced build after all these steps can be downloaded from Jenkins’ Artifacts and also uploaded to dropbox.
- On this generated APK UAT, performance and functional espresso tests are executed to make sure that the final release APK is ready after all the tests and can be uploaded to the distribution console or Google Play Console.
iOS CD Workflow
iOS CD Workflow checks out the latest release candidate code base and creates the IPA for release and uploads it to Testflight.
- Release ready IPA can be downloaded from Testflight on iPhone devices for UAT and Regression testing.
- After all the testing is done, the Release team can promote the app from TestFlight to Apple Appstore.
Tools we used
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:
- Create automated workflows with standardized processes (like — JIRA ID in PR Title, dev-tested label on the PR) across the organization.
- Catch errors early in development cycle like — compilation failure, Invalid config files, unintentionally increased app size and non-standard coding practices etc.
- Find and fix functional errors using functional sanity tests early in the development cycle.
- Ensure that the application is released with client side security.
- Create release ready applications without human intervention, thus saving time and human effort.
With the help of CI CD workflows Rush Release Team is able to timely release the app with required quality and robustness. This CI CD system is scalable, low maintenance and can be applied to multiple applications.
