Avoid CI/CD Lock-in — Make Your Builds More Portable
We recently migrated our Android CI/CD pipelines from Bitbucket/Bamboo to Gitlabs. If you follow my blog, this is something that we had planned to do in our Engineering road map during the year. These CI/CD products have their own pros and cons and are really not about which product is better but how to make the move easier when an enterprise decision to change products is made. Even if you are not using Bitbucket/Bamboo or Gitlabs, following the principles outlined in this article should minimize any potential effort to migrate your CI/CD in the future. Before we do that, let’s look at the 3 key functions of your CI/CD.
- Scheduler — This allows you to create daily, nightly, or weekly builds, etc.
- Trigger — Determines how your build jobs are started. This is usually automatic by pushing code to a repository or manual by pressing a button in the UI.
- Orchestrator — How different build jobs are organized to form a pipeline.
If you keep this in mind, it should make it easier to decide where and how to configure your CI/CD. If you are doing extra stuff in your CI/CD, consider moving it to a more appropriate place.
Here are few simple tips to help improve your builds portability;
- Keep your build scripts in your code repository. It means that you can easily track changes and change your builds without impacting other branches.
2. Put your Gradle commands in a shell script. It means that multiple Gradle commands can be easily executed by a single script and it’s easy to maintain the parameters used in your build. A well-formatted shell script is much easier to read in an editor like Android Studio than your CI/CD’s UI.
3. Use Gradle Plugins over CI/CD Plugins where possible. All Gradle commands can be executed anywhere however CI/CD plugin can only be executed on your CI/CD pipeline. If you aren’t using Gradle, this also applies to any other build technologies e.g. Maven that you might be using. Jenkins one of the most popular CI/CD servers has over 1500 plugins!
4. Use containers - they ensure your builds are portable and reproducible, nearly all the modern CI/CD solutions use them.
5. Minimise your configuration in your CI/CD. If you use a single shell script (or a minimal number) to execute each build job, it keeps things simple and easy to maintain. It means that configuration in your CI/CD configuration should rarely change.
Our migration from Bitbucket/Bamboo was a breeze, and amazingly our Gitlab YAML file was no longer than 106 lines. I hope you found these simple tips useful and stay tuned for more.
Note: I don’t write as many articles as I used to and the main reason is remote work. I used to spend most of my commute to work writing articles to pass the time but that’s not happening anymore. Maybe as we return to the office you might see more articles in the future!
