The Process to Upgrade Build Systems for Mobile SDKs

Every year Apple and Google launch a new version of Xcode and Android Studio with new features and capabilities. Following are the major reason for adopting newer build system -

• To add support for new OS versions
• To use new features and capabilities
• To adopt a new SDK packaging style

Hence, we have to upgrade our build system from time to time. But we might face issues while upgrading the build system and that might break our CI pipeline. So, we need to make sure while moving to a newer build system the transition is as smooth as possible for us and our customers as well.

The objective of this blog is to share the process and learnings that I have had in the past while upgrading the build system.

The process can be broken down into 3 steps, just like Kurt Lewin 3 Stage Model.

Kurt Lewin developed a change model involving three steps: unfreezing, changing, and refreezing. The model represents a very simple and practical model for understanding the change process. For Lewin, the process of change entails creating the perception that a change is needed, then moving toward the new, desired level of behavior, and finally, solidifying that new behavior as the norm. The model is still widely used and serves as the basis for many modern change models.

🧊 Step 1: Unfreezing

Before upgrading to a newer build system you’ll have to first understand what you are currently using and where it is hosted. It can be Amazon EC2 Instance or a machine set up at the office.

• First, know where your build system is hosted. After that see how you can connect remotely to it. Here, you might need to ask someone from the DevOps team at your company or someone from your tribe.
• Multiple versions of build systems can be installed, so make sure you double-check which one is exactly being used.
• Note down the current version of the build system and OS version on which it is hosted in your notes.

Note down the new build system’s minimum OS version requirement or other requirements (if any) in your notes. If there are multiple build system candidates that you are considering as of now and yet to decide on, then note down setup requirements for each candidate. You can always find those requirements details on official docs by Apple and Google.

Test plan plays a vital role in upgrading the build system. So, you will have to come up with a test plan. The test plan should ideally include test cases wrt the following audience —

• Your tribe — Here, we need to check if the project builds fine, scripts for dev, QA, and release workflow work fine, and unit tests and UI tests are not failing due to the newer build system.
• Your customers — Here, we need to run sanity tests on SDK created from the newer build system. Sanity tests should also include a test for app submission to App Store and Play Store to check if it doesn’t fail because of SDK built from a newer build system.

If you are using Git then stick to the latest commit on the master branch of your repository or else stick with the latest stable and released change that has been done on your repository.

For each build system candidate fill up the table that we created above. To fill the table, you’ll have to install a build system on your machine. You can install them one at a time if you have memory space issues. Add them in your notes and get them reviewed by your tribe and manager. If you have any doubt about test scenarios, then ask within your tribe. If there are multiple candidates for the build system, set up a meeting with your tribe and manager to finalize the right candidate.

NOTE: While filling the table it might happen that there isn’t any solution or multiple solutions for an issue. Kindly document it and discuss it with your tribe.

After finishing the First Step make sure you have answers to the following questions —

• What is the current OS version of the machine where your build system is hosted?
• To which version of the build system you are going to upgrade?
• What is the minimum OS version requirement for that version of the build system? Are there any other requirements (if any)?
• Do you have to upgrade the OS of the machine to support a newer build system?
• Is there any other setup work that needs to be done on the machine for the newer build system (if any)?
• Is there any impact on your repositories after moving to a newer build system? If yes, then what are those?
• Is there any code change required in your repositories to adopt a newer build system? If yes, then what are those?

Make sure you have answers to the above questions in your notes.

💧 Second Step: Change

This step involves two major tasks. Consider them as two subprocesses. Now since our human brain is a uniprocessor you can work on these subprocesses in Round Robin Scheduling fashion (you can keep your quantum flexible though, but make sure you are making progress on both the subprocess).

1. Setup work to be done the machine to adopt a newer build system

• Create a new doc and list down all the setup work that needs to be done.
• For the setup work, you will need help from IT support and the DevOps team. So, you will have to sync with them.
• Set up a meeting and explain to them what setup work is needed. Share the doc with a list of all setup work that needs to be done, get an ack.
• Come up with a plan and action items for people after the meeting. Make sure your plan has minimum impact on other tribes. For exa — The android build system is not affected by iOS build system changes. Or other devs can continue to push commits in standard working hours, etc. Also, think of worst-case scenarios that can happen while doing setup work and have a fallback plan for it.
• While performing setup tasks keep everyone (this includes your tribe members, DevOps, and IT Support) in the loop.

Tip: Don’t delete the existing build system immediately, just change the application name for the time being. Because, if you face an unknown issue with the newer build system you can immediately fall back to the older build system. This will unblock other devs and you can investigate the issue separately.

NOTE: After upgrading to newer build system there might be some impact because of the setup work that you have done (I hope here isn’t any🤞). If there is, try to find the root cause of the issue. Set up a meeting with DevOps and your tribe. Try to figure out impact areas and solutions for it.

2. Code changes (if any) to be done on your repository

• Create a new doc and list down all the work that needs to be done. This can involve minor to major code changes (for major changes you can document them in another doc). Make sure you have documented those changes with their impact (if any).
• Get them reviewed by your tribe and manager.
• While pushing those code changes, tests might pass or fail. Failure can only happen if an older build system is being used and has got affected by newer code changes. Thus, you need to focus more on upgrading the build system (go with Priority Based Scheduling). Once, it’s done you can start pushing your code changes.

❄️ Third Step: Refreezing

Push a test change on your repository to check if the newer build system is working fine in terms of running tests on the code changes. You can abandon the change once you have verified that.

Next what remains is to test if the generation of release artifacts works properly. So, what can be done to test if release artifacts work properly is to do a dry run of release -

• Go through your release process. Figure out how you can perform a dry run.
• Get in touch with current DevOps on-call keep them in the loop and discuss what, why, and how you are trying to test.
• Start your dry run. If anything fails try to figure out what might be the reason for it and then discuss with DevOps on-call to come up with a solution.
• If nothing fails while performing a dry run then congratulations! You have successfully upgraded the build system 🎉.

NOTE: Make sure you perform this dry run well before the release day (IMO at least 2 weeks before).

Besides running the tests on code changes and creating artifacts if there are any other workflows that your build system performs then make sure you test out those as well.