How we improved iOS release process at conichi
I’ve been working for conichi and currently is leading an iOS development team. Recently we have significantly improved our release process that saves us a reasonable amount of time and lower the human error possibility.
At the moment our team is working on two iOS applications: guest and merchant, and our SDK that we share with our partners and also use in the guest application. So now when you have the general overview let’s go to the interesting part — evolution of our release process.
Back to the days
Focusing on guest and merchant applications the initial release process was super simple:
Once we had to debug app store version from the master branch of the guest application and it was a pain to find correct commit we started using github releases for iOS apps as well as for SDK. That helped us a lot to control the code base for each version of our app.
Next change in our release flow was forced by a decision to write a release notes for both github release and fabric build. That has been done manually by looking through closed JIRA issues in the specific period of time. That was not a big deal, but eventually it was annoying to look through all issues and create a summary from them.
As you can see it became 6 steps with a loop on the “push to fabric”. Because if our testers find a bug we need to fix it and repeat all steps again. You can imagine how much time we spent on it.
Our CI runs test on every PR only on only one simulator and after couple of platform/iOS SDK specific bugs I forced the requirement to run tests on all supported devices before publishing new version to either Fabric or App Store. So eventually all steps that we did to release our iOS apps were:
This finally drove me crazy and I started looking for something to automate all of these.
Nowadays
Fastlane
Luckily I read couple of month ago about fastlane and it was a good chance for me to become familiar with it. I began with project’s readme and also found very useful this repo with fastfile examples from other teams. Most of the inspiration I took from artsy iOS project.
Since we have two apps: guest and merchant I ended up with shared fastfile with utilities actions and project specific fastfile for each of the apps. I’m not going to deep into detail of fastfile implementation here, instead I open sourced our example with description for the most of lanes inside.
Danger
This was a great start, but than we faced a problem how to keep CHANGELOG file up to date. And again, recently some cool guys have created a project called Danger. The purpose of it is to formalize pull request rules for the team. So I’ve created a rule for our pr — it has to contain CHANGELOG file modification if more than 50 lines were modified/added/deleted and if there is no specific flag to skip change log verification.
In the conclusion I can suggest everyone to try out these tools. I’m pretty sure even if your project does not need these all steps to make a release, anyway it will save you lots of time that you can spend on something interesting and not routine or you can even have a cup of ☕ =).
