CI/CD & The Mobile Build Train
CI/CD for simple backend services and small web applications is straightforward. Yet, even for simple mobile applications, it is less so: mostly because of the manual submission step for the app store. Doing a fully automated continuous deployment pipeline is impossible to do so for iOS App Store apps due to the manual review gate. On Android, you can automate this process, as you can with enterprise iOS apps.
You can’t have a fully automated continuous deployment to the App Store on iOS, thanks to the manual App Store Review process.
iOS and Android platforms are different: each require their own build systems and separate pipelines. When going with a third-party CI, it’s worth choosing one who treats iOS and Android mobile builds as first-class, has a track record with mobile and can handle the scale your team or company is looking at. There are several vendors you can explore.
Bitrise is CI/CD built for mobile by mobile engineers. From pull request, to app store submission and beyond, Bitrise automates, monitors and improves your app development workflows. Teams who use Bitrise build better quality apps, deliver them faster, with developers who are happy.
Bitrise supports native Android, iOS, React Native, Flutter and builds with other popular mobile frameworks. Need support for a specific development step like testing, code signing, or notifying when a build has issues? With an open source library of hundreds of integrations you will probably find what you need, or be able to build it quickly.
More than 100,000 developers and thousands of organizations trust Bitrise. Try it for free and build better apps, faster.
Owning your own build infrastructure could give you more control and better experience than using cloud-based CI/CD vendors. Mobile engineering leads at several engineering companies have noted they are happier with having their build infrastructure in-house, even with the additional cost.
At (very) large scale, you might decide to build in-house: at Uber, we did not have any vendor who could have handled the amount of builds we were doing reliably, nor could they have provided the integration hooks our in-house system did.
You’ll probably find yourself using popular build tools to automate various build steps, such as uploading to the app store. For iOS, this will likely be Fastlane, and for Android builds running on Jenkins, it could be a Jenkinsfile or something similar.
Be wary of maintaining your homegrown CI system if you won’t have dedicated people bandwidth to support this. I’ve seen startups repeatedly set up a Jenkins CI, get it running, just to realize months later that someone needed to keep dealing with infrastructure issues. I strongly suggest either to buy a vendor solution - and offload the infra part to the vendor - or have a dedicated person or team own the build infrastructure for mobile.
For large companies, owning the build infrastructure might make sense: at Uber we had a dedicated mobile infra team who owned things like the iOS and Android monorepo or keeping master green, at scale. Other companies with large mobile teams, and enough resources also run their own CIs, using dedicated hardware. At the same time, companies like Rakuten have moved from an in-house CI setup to Bitrise, and are happy with the change.
The build train is the next step after you have a CI in place. A build train is a way to track the status of each of your weekly, or bi-weekly releases. Once a release cut is made for a “release candidate” for the app store, a series of validation steps need to happen: some of these automatic, some of them manual. These steps include running all automated tests, manual testing, localizing new resources, performance tests or a dogfooding or beta testing period.
Once the release candidate is validated, it is uploaded to the app store, and waits on approval. After approval, you might roll out with a staged release - a phased rollout on iOS and staged rollouts on Android.
Your build train would visualize the status of all of the above: which commit was the build candidate cut, where the validation process is, and what the staged rollout status is. Build trains might be manually tracked by people owning the release process, and some companies with complicated release steps and mobile infra teams sometimes build their own homegrown solution.
The Apple and Google interfaces let you track what happens when you submit the app for approval. However, you’ll want to ensure a series of quality gates are passed after a build cut is made, and before you submit this build. These quality checks usually involve manual and automated tests, localization tests and could include a dogfooding period among others.
You are reading an early draft from the book Building Mobile Apps at Scale. For the final, expanded and improved content, grab the book now - it's free to download as a PDF until 31 May.
Building Mobile Apps at Scale
"An essential read for anyone working with mobile apps. Not just for mobile engineers - but also on the backend or web teams. The book is full of insights coming from someone who has done engineering at scale."
- Ruj Sabya, formerly Sr Engineering Manager @ Flipkart