CI/CD With Jenkins, Docker and Fastlane — Part 3 — Jenkinsfile and Fastlane
This is part of a multi-part series about CI/CD flow. This post focuses on what we do in our Jenkinsfile and Fastfile.
Other articles in this series:
3) Writing Jenkinsfile
A Jenkinsfile includes all the steps for a CI/CD process. We use a basic Jenkinsfile. It includes informing Slack, building and deploying beta and prod.
All the variables are defined before the pipeline keyword. We define the poll interval for Jenkin’s GitHub plugin here. Master is our release branch and it is checked every minute. Test branch is for daily beta release channel and it is checked at 00:00 AM.
We activate ansiColor plugin for every build at options block. Triggers block is to specify polling trigger. Rest is the steps.
3.1) Init Step
At init step we are getting last commit information to send slack. If commit string contains [skip ci] we are going to skip the build with setting env.shouldBuild to false.
3.2) Run unit and ui tests
This stage runs the tests and reports errors. If you don’t try catching test errors, it will mark the build as fail, not unstable. When a branch has failed tests, worker can build the application but CI will not let the code integrate into main branch, so we mark the build as unstable and exit.
3.3) Build application for pre-prod environments
In this stage we are building our application before sending to beta. This process lets us identify errors early. When you find errors early you can stop release process and you will have a very small set of users that have buggy version.
3.4)Send to beta
In this step we deploy new build to pre-prod servers.
3.5) Build for prod
In this stage we build application for prod servers.
3.6) Deliver to prod
We send tested build to prod servers after the beta. With this way, we are testing the parts of the application we haven’t wrote tests yet, and then submit manually.
3.7) Inform slack for successful build
Notifying slack has its own stage because, when a commit has [skip ci] flag, we are skipping all the stages. If we put success notification to the post build actions, it will send a success message after skipped message. Skipped stages are successful stages in the Jenkins eye.
3.8) Post build actions
This is where we inform slack for failures or unstable builds.
4) MultiPay iOS CI/CD Workflow
We are using a tool called Fastlane for iOS and we need to add extra steps for keychain initializations.
4.1) Fastlane and iOS
Fastlane is a tool to automate testing, change version and build number, generate screenshots and deploy to beta and store. Fastlane reads a file called Fastfile and it has lanes. Each line is a set of instructions to create a flow. Fastlane instructions are called actions.
Fastlane makes it easy to build and sign applications. If you don’t know what is code signing and how certificates work, you can have a look at this blog post:
Basic fastfile can be like this:
This fastfile will define two lanes. You can run them in project root with “fastlane beta” or “fastlane release”
For integrating the Fastlane to your project, you can have a look at this link:
4.1) Recreate keychain
In this stage we are first trying to delete Jenkins keychain if it exists. It can solve an issue:
Then we create the Jenkins keychain and unlock it, so code signing tool can access certificates.
Identical fastlane lane is here:
4.1.1) Populate keychain with certificates
In this stage we are populating the newly created Jenkins keychain with application certificates.
4.2) Install Pods
In this step we are updating pod repo and installing pods. If you don’t specify deployment, cocoapod will look for latest versions in pods. If you don’t specify repo update, one or more pods can be released after the latest deploy machine repo update.
4.3) Increment build number
4.4) Run unit and UI tests
In this step we are running the tests. There is a code coverage report too.
4.5) Build application for beta deployment
4.6) Deploy application to beta
We are putting release notes into a file and we added it go gitignore. This way, our git repo stays clean.
4.7) Build application for prod
Identical lane is given in 4.5.
4.8) Deploy application to prod
We use phased release. Phased release deploys new version to users with specific groups each day. It takes 7 days to deploy to all users. You can see the days and deploy percent in the image below:
We are not submitting automatically because we don’t have enough coverage with tests, and we don’t generate screenshots, so we don’t submit any.
5) Troubleshooting
5.1) Jenkins triggers builds when there is a build going on
This can happen with the increment_build_number_and_commit lane.
The reason is; let’s say we made commit “A”. Jenkins will pick it up and trigger a build. It will pull latest changes and start the build. We are making a commit before the build phase for version or build number, and we need 15 minutes or so for our application build file generation. In this timeframe Jenkins will try to poll SCM and see that our build number commit didn’t get a build and queue one. If you told Jenkins to look for changes every minute, this can mean 15 build in the queue.
For the solution, we can commit changes just before the slack success message. We can put a stage at the start to be sure that we have a clean git status, then we can make all the changes and commit at the end.
