When developing a mobile app, you should not fear automation. Rather you should welcome and encourage it, especially when it comes to ongoing development after the initial launch. However, there’s a catch. You’ll have to know what tasks are suitable to automate, so you can actually speed things up and avoid tedious repetitiveness.
CI/CD or CICD (Continuous Integration/Continuous Deployment) is a good approach to take. In simpler terms, it’s a method of frequent app delivery by making multiple changes to the codebase simultaneously.
However, to avoid the reality from the xkcd sketch below, picking the correct tasks to automate is crucial. Therefore, you should always:
- Analyze your problem first;
- check if it aligns with the CI/CD approach;
- use an open-source platform, such as fastlane, for its implementation.
Step 1: Analyse Your Problem
Let’s imagine you started a new project with your team. At first, things are going well. You could almost say you are on a roll, finishing feature after feature in record time. Yet, there’s a catch. After every feature, you need to make a new build for the QA (Quality Assurance) team, meaning creating and distributing it.
However, things don’t always go as smoothly as one would like when it comes to testing – QAs find minor bugs in some features. Indeed, you can quickly resolve them. Yet to do so, you still need to stop your current task and prepare new builds for testing. You resume your work after, whilst needing a little time to adjust and get back into the workflow. These events can happen often and might not bother you at first, but as time goes on, they become a burden.
One easy solution would be to assign the build and upload responsibility to the person who owns the task. This would, for instance, offload the work from only one person to multiple people and would sound like a lovely idea if only one person was building at a time. However, in the opposite case, only one build passes while the others get rejected. So, what should you do here? Perhaps make a system where you communicate to the team that you are starting a build? While this could work, it's only a workaround rather than fixing the core problem. To do the latter, CI/CD would be a better approach.
Step 2: Understand CI/CD Approach
CI stands for Continuous integration, a development practice for merging a developer’s code multiple times daily and ensuring that everything runs properly. It includes making builds and running tests but is not limited to that. In layman’s terms, your code is built on a remote (or local) server where you can also run tests. Merging your code into the source branch is often coupled with a set of approval steps from the CI, such as running tests or linting the code. Testing often helps us catch regressions or bugs earlier.
CD or continuous delivery is the process that follows CI, but not necessarily. For example, once a build is successfully created, CD takes over and distributes it to your service of choice. This process can also be automated and transformed into continuous deployment, where releases can be handled automatically.
Now that we got the basics down, we can use this newfound knowledge with a tool called fastlane.
Step 3: Use fastlane
Fastlane is an open-source platform that helps us simplify a plethora of deployment processes. It works for iOS and Android apps. I would even go as far as calling it an industry standard as big companies such as Soundcloud, Product Hunt, Wikipedia, and many more have already adopted it.
Automating your app’s build process is one of the essential things offered. It also supports uploading your build to various CD platforms such as Testflight, Firebase app distribution, TestFairy or DeployGate. Maybe you need to generate or upload new screenshots on the store listing page? Or do you want to automate the whole release process? fastlane has got you covered. In a nutshell, if it’s something reasonable you require, it probably can be done. And if not, since it’s open-source, you can write your own functions with a little bit of Ruby. Most major CI platforms support fastlane out of the box, naming a few such as Bitrise, CircleCI, Jenkins, Travis CI, etc.
How to fastlane?
To jumpstart your CI/CD experience, you first need to install fastlane on your system. It's as easy as running the following command into the terminal: brew install fastlane or sudo gem install fastlane
After successful installation, go to the root directory of your project via terminal and run the following command: fastlane init
This will start adding all the necessary files into your project directory and make fastlane available for use.
How to enable remote building with fastlane?
When a project is not intended for remote building, its signing mode is probably set to automatic, meaning Xcode handles the registration of new entitlements, registering new devices, expiring certificates, etc. Though this is handy, it can become a real hassle when you build remotely. Because of the remote environment, you need to have certificates and provisioning profiles in order to sign the app and distribute it. Of course, you could manually download these profiles and upload them into CI directly, but since automated code signing via Xcode tends to modify these certificates as needed, they can quickly become obsolete, and building/distributing won’t work.
Here’s where fastlane’s match comes to our rescue. It offers automatic certificate and provisioning profile generation, all while encrypting and storing them into a secure repository where this can be accessed by your team members or the CI who is responsible for building the app.
That way, you can offer a synchronized location for all your certificates. It also supports multiple targets, teams, automatic device registration via a dedicated file and similar.
Setting up a match for your project is as easy as running the following command:
fastlane match init
After following the setup instructions, you must also set code signing in Xcode to manual and select the newly generated certificates. With this done, you are ready to move into your CI of choice.
