What is continuous integration?
Here are a few things that constitute continuous integration in my eyes:
- store your source code in version control system (git, GitHub, GitLab, BitBucket or another)
- Frequently integrate your code (don’t go work on a feature for three week before merging that code back in master)
- Automatically build you application and verify this build
- Have unit test, integration test and UI test and run them automatically at each build to verify the build
- Automatically release build to your beta platform of choice and to the store
Why adopt continuous integration?
- Know that the application is always ready. Once you have those test in place and they run at each build you should feel more confident about releasing it.
- More trust within the team. With those regular build you know that what was committed has a certain level of quality, an impartial referee can call out what is broken.
- Increase app quality. Catching bug sooner, more often will translate into a higher quality app for your user, and most likely better reviews.
- Know what has been deployed to production. Since your server is now doing the release, you know exactly what was release, not some adhoc version that the developer put together before release because what was in git was not building.
What are the downsides of continuous integration?
- It has a setup cost, setting up the build automation, creating automated tests.
- You’ll want to adopt a few best practices (code reviews, git flow, unit test and its variants)
- At first it will slow down the team while the team figures out how to best adopt those practices
Yes, like everything there is a cost to continuous integration, but honestly you will recover that cost very quickly. You should see fewer regression, fewer bugs that go into production, a faster overall release cycle.
How do you go about adopting continuous integration?
First like I mentioned, you’ll want to adopt a few best practices.
- Branch management system. We like gitflow, i’m sure there are others, pick one that works for you.
- Pull request and build on pull request: unless you’ve adopted pair programing, you should do pull request, someone should do a code review on that pull request and the pull request should be built by your continuous integration platform and tests should pass before the pull request is allowed to be merged.
- Makes sure you know how to build your app. For a client of mine, I asked: how do I build the app? The answer: just hit build in Xcode. Well, it was not that easy, the developer forgot about a bunch of dependencies, private cocoa pods. So make sure you can take a clean box, follow a few steps and build your app.
A few platform options for continuous integration
Here are a few common feature across those solutions:
- integration with GitHub, gitlab, bitbucket or other git server
- different steps/configuration of your build based on the branch, tag that was pushed to git
- ability to build pull requests
- Delivery of app to store, beta services
- Build environment variable if you want to keep a few keys out of your source code
In Appfab we chose Microsoft AppCenter