Following on from my last post in the series, on how we develop software with maximum efficiency and minimal interruptions, I’m going to explain how we set up both Jenkins and Fastlane to deploy builds to our QA department.
Configuring a Continuous Integration server can be a little tricky the first time around. As with everything you do in life, it takes time and patience to master and feel comfortable with. In this post, I will detail how we set up our pipeline in order to deliver builds to QA with ease for every feature that we develop.
Our approach may not fit your specific needs but you can use it as a base to experiment with before configuring it to suit your requirements. If you have any queries, I’m an email away.
A few notes before we start:
Installing Jenkins is pretty straightforward, thanks to their useful User Documentation, which gives users access to handbooks, tutorials and guided tours.
Similarly, Fastlane offers a whole host of setup docs to get you started.
However, I do have a top tip for you! I’ve been experimenting with Apple’s system Ruby and I would advise that, in this instance, you opt for Ruby Version Manager instead. Ruby Version Manager installs each version of Ruby straight into a hidden folder in your home folder so it doesn’t affect the system Ruby. There’s a helpful installation guide online if you’re looking to follow suit.
When using RVM and RubyGems to install Fastlane, I found that the Jenkins job was not able to find Fastlane so I installed the Jenkins RVM plugin and specified my Ruby version like this…
Our basic job configuration checks out our Git project using Jenkins Git plugin. It then executes the appropriate lane of Fastlane.
We use Bitbucket so we first need to set up a Cron job that will trigger a build in Jenkins whenever a PR is opened in Bitbucket. In order to do that, we installed the Bitbucket pullrequest builder.
This is our configuration:
CRON: Use * * * * * and it will poll Bitbucket every minute to check for PRs.
Credentials: Set up a shared credential that you can use across all projects.
Repo Owner & Name: You should take the data from your repo URL/SSH, for example:
Branches Filter: You can choose to only build specific branches or leave it blank to build all.
CI Identifier & Name: We use Jenkins as our CI identifier and Project Name.
I’m now going to detail the Fastlane actions defined in the Fastfile. We use Fabric to distribute our internal builds to QA, so I defined a Lane to build and deploy to Fabric. An environment variable with the Fabric API key is set.
We don’t want to accidentally deploy uncommitted changes so we also checked the Git status.
Before we build, we need to acquire the version number and increment the build number. We enable Fastlane to handle automatic version incrementing for us. When doing so with an iOS Application, we use Apple Generic Versioning. There’s plenty of advice online as to how to set up automatic build increments so the process is relatively painless.
It uses a scheme for deployment and also handles signing for us.
With our build finished, we then upload it to Fabric.
And now that our build is deployed, it’s time to notify the team that there’s a new version available. We created a new Slack web-hook and added an environment variable that means, when a build passes, a notification gets posted to Slack to let everyone know that there is a new version available.
If the lane fails, it will also post to Slack. To ensure we keep on top of it, during the development process, we made the following adjustment:
Before committing the changes we’ve made to the changelog and Info.plist files, we need to clean any build artefacts. This includes the actual binary that was compiled, as well as the unit test coverage reports, and the downloaded provisioning profiles.
Jenkins is an open source automation server that is flexible enough to meet our specific needs, allowing us to scale as needed, meaning we can add as many jobs as we want without having to upgrade the price plan.
We did, however, once lose Jenkins configuration, so I encourage you to put the Config file under source control! Fastlane is now developing its own CI which I will be keeping an eye on in order to test it as soon as it’s released. Keep your eyes peeled for a future blog post on that!
Automating our deploys helps us to do more of them, as it reduces the complexity of testing and helps us to uncover bugs promptly. It has been extremely useful across the board, in all of our projects, and it’s something we recommend.