Shipping iOS at RedMart

Everyone loves shipping software! What’s better than seeing your code go live on the AppStore, right?
In this blogpost, we will briefly touch upon how we improved the build and release process for our iOS app.

Tools and Infra:

TL;DR: TravisCI + Fastlane

In the past, our iOS app release process involved uploading the package through Xcode/Application-loader. We previously had shell scripts to automate this, but due to not used/maintained for a while, they were not working for the latest version of Xcode.

So, we had the option of understanding and fixing these scripts, but we realised that it would be wiser to instead invest in something that was:

1) Easier to understand and use.
2) Easier to build on top of.
3) Easier to maintain in the long run whenever Xcode and iTC made changes.

Fastlane was our consideration for this as it seemed to check the boxes and our also devs had good things to say about it from prior experience.

Another bonus we got by using Match in Fastlane is that we no longer had to manage several certificates and provisioning profiles for each dev, as a single copy was encrypted and stored in it’s own repo resulting in a easy to maintain dev-portal and no dependency on a dev / computer to make a release.

As for the hardware, Travis had good integration with GitHub and we use it for other projects at RedMart so we decided to go with it.

Process:

TL;DR: Release-schedules. A little discipline keeps everyone happy.

There were times when we did multiple releases in a week, which in retrospect could have been avoided if we had planned releases and managed expectations better.

So we introduced a release-schedule. This made our release-cycles predictable, in-turn allowing our QA to plan their calendar accordingly and also for other stakeholders to have a clear idea on when a particular feature could be expected to go live.

So our release-schedule looks like:

1) We send the RC for QA and also dogfood it to the whole team every Friday.
2) The team uses this RC for their shopping over the weekend. This helps us get early feedback/concerns.
3) Our QA gives us a sign-off by Tuesday morning, post running automated regression tests and a manual check based on the change-log.
4) If all goes well, we make a release with all the changes. Else we revert the buggy commit and proceed to make the release.

As iOS App releases are relatively expensive in terms of time for approval/go-live (Typically 12 hours) and fragmentation of build version on users’ devices, we try to give the code on master enough time to be tested by QA and used by internal test group before taking it live.

All in all, this setup has saved us countless hours of time and effort. Now, we just trigger the build and catch a colleague for a game of foosball :)

Summary:

Originally published at geeks.redmart.com