Here at Greenhill, we subscribe to the maxim of Release Early, Release Often.
We find that this not only keeps the energy and freshness of a project high, but also helps keep an app’s roadmap and priorities more closely aligned with user feedback.
During busy periods, this philosophy means that we might release two or more app updates per week.
Hectic days require cool heads
Release days tend to be very busy.
We’re always eager to get our app’s new features out to the public, but stability is paramount so we take care to temper our enthusiasm and test thoroughly.
We have to ensure that our new features are robust and bug-free, but we must throughly test existing functionality too, to ensure that the process of integration has not caused any previously tried and tested features to regress.
Merging and Testing
We use the Gitflow Workflow as our branching strategy.
Before being ready to build a production release, I first need to merge all relevant feature branches for our release into the develop branch, then into the relevant release branch (say, v2.53), before finally the updates are fit to merge into our master branch.
The trials, tribulations and conflict resolutions required to perform those merges successfully are a topic for another blog post! But suffice to say that the combination of i) supporting multiple mobile operating systems; ii) reconciling numerous mission-critical frameworks and libraries; and iii) integrating multiple developers’ work can be challenging. You need to be dedicated and diligent.
Building the app
We use Xcode for iOS builds and Android Studio for Android builds. Xcode isn’t the most user-friendly application, but it has improved in its last few updates.
When building an app file, you can find this is blocked for a variety of reasons.
Build errors occur most commonly due to problems in code updates, but can also occur if third party plugin dependencies need updating, or two plugins are incompatible. More dedication and diligence are required as we put our heads together to resolve conflicts.
Simulators are no substitute for testing on a real device
Once I know I can successfully build, I’ll do a trial run where I’ll build and deploy to my own phone. At this stage, you’d be surprised by how many features which worked during previous testing in device simulators now fail or perform differently when tested on a real device.
Now that the app is on my phone, I can do a final test-drive of all the new features and bug fixes. I’ll also run through a list of typical usage scenarios (registration, signing in, buying etc) to use the app as a normal person would, ensuring that no new bugs have been introduced.
If all is good, I then make sure the app’s version number has been incremented, otherwise it won’t be accepted by iTunes Connect or Google Play. (Once, I encountered an issue where an app’s releases were blocked by Google Play for a week because it didn’t recognise or accept the version number).
One last but important step is to make sure that all environmental variables are updated for public release. Development releases tend to be connected to staging data and staging APIs, whereas public releases need to point at production data and production APIs.
Signed, Sealed, Delivered
I am now ready to build the .apk file for the production release. The .apk that is produced is unsigned so I need to create a signed version.
For iOS, I can do this in Xcode. After opening the project, I make an Archive, then upload this Archive to the App Store. After waiting until the app has been approved for distribution, I log into iTunes Connect then deploy the app. First I will deploy an "internal testing" release but once happy with that I can easily upgrade it to a production release.
For Android, we use Android Studio to create the signed .apk. The final step in getting our app out to our Android users is to upload the signed .apk to Google Play.
Last checks
Having downloaded the update, our final step before announcing the new release is to install, sign in and run through the critical path. This is just to make sure there were no unexpected problems in the build process.
High-fives all round!
Whew, what a day. Back tomorrow to prepare for the next release!
