As an agency, broadly speaking we have 2 different types of customers. The first type are those who need an app built, which once released will only receive infrequent updates, perhaps to add a new feature or fix a breaking platform change. The second type are customers who require constant maintenance and updates to their app.
Release strategy for the first type is pretty straight forward. Once development is finished and QA have signed off, the app can be shipped. If any serious bugs come to light from the public release then we follow up with a patch. Case closed.
However, for projects that are in constant development things become more complex.
Typically we may be adding a new large feature perhaps once every 2 or 3 months, with smaller features and UI updates every couple of weeks or so. Also, on large projects there will be ongoing constant bug-fixing.
So when and where do we draw the line when deciding to do a release?
Traditionally this would have been done when one of the large features was finished. When <Super New Feature> is ready, a build is made with it and all of the other updates and bug-fixes since <Previous Super New Feature> was released. More and more however, companies are transitioning to a more regular and frequent release cycle, and there are a number of advantages to this.
The problem with waiting for a certain feature to be ready before doing a release is that if the feature gets held up, then so does the release. It may not even be the main feature that’s delayed, it could be a smaller feature that’s tantalisingly close to being finished, so the release is held up for it, even though everything else is ready. The problem with this is sometimes that 99% finished feature actually turns out to be further from being finished than expected.
The result is that users are forced to wait even longer for the completed features and all the bug-fixes made since the last release.
This isn’t a problem if you adopt a frequent release cycle. If a feature isn’t ready on time, just go ahead and release without it; the next release will be along soon so we can add it to that one.
A fast release cycle also allows you to respond to user feedback and fix bugs much more quickly. According to the Google I/O talk, users are 26% more likely to give a 1 star review on days when your app is at its crashiest (rising to 52% for games), and they’re 38% more likely to mention stability in reviews on those days. This illustrates how important it is to be able to respond to bugs.
Even with the best developers and QA people, we can’t guarantee a bug free app, but what we can do is fix those bugs quickly and get the fixes to users as soon as possible.
With a traditional slow release cycle you can still release a patch for serious issues, but less severe bugs tend to get pushed to the next release. For users experiencing those bugs, it can be very frustrating if they’re not fixed in a timely manner and can lead to an impression that the app isn’t actively maintained.
With a fast release cycle, fixes for those minor bugs will be rolled into the next release, which is always just around the corner, so the user never has to endure them for long.
The same goes for issues arising from OS updates or new device releases. Once a fix has been implemented you know that it won’t take long to get to end users, and it also involves less effort as developers don’t have to create special hotfix builds and QA don’t have to test said builds separately.
On the subject of QA, this is another area where frequent releases actually helps. If you’re doing infrequent releases, there can be a lot of features, code and bugs added since the last release.
This means that when an issue is found, it can be hard to trace its origins.
On the other hand, if there have only been a relatively small amount of changes since the last release, then it makes it much easier to identify when and where a problem originated.
QA people also have a tendency to find bugs just before the build is due for release (oh I went there ;D). With a slow release cycle this means that we generally need to delay even further until all known bugs are fixed.
With a fast release cycle however, it’s much easier to persuade them to let the release go ahead as the bug can be fixed for the next release, which will be along soon.
Our rule of thumb is that if it’s not a regression (i.e. the bug already exists in the current release) then it shouldn’t hold up a new release. To do so would only deprive users of fixes for other issues that have been made since the last release.
At the same I/O talk they discussed a number of new and existing tools that can assist in accomplishing a faster release cycle. These are Android Play Store specific but similar tools may exist on other less popular platforms such as Blackberry, Tizen and iOS.
The Play Store has had Alpha and Beta channels for quite some time, but these weren’t necessarily the best options for distributing builds internally. In particular, it could be slow, with builds potentially taking several hours to process. Also, some teams might need finer grained distribution options. These problems have been solved with the addition of internal test tracks.
You can create custom tracks for various levels of distribution, such as to your dev team, to QA or to your client. Builds uploaded to these tracks are available within seconds instead of hours!
This means that third party tools such as Fabric or Hockeyapp aren’t necessarily needed any more.
When the time comes to release your build, it’s always a good idea to release it to a small percentage of your user-base first.
Even with thorough QA, issues are bound to surface after you release to thousands of users.
If you do a staged release then you can wait to see if any serious issues emerge before rolling out to all users. This means that if there is an issue found that requires a patch, only a small amount of your users will be affected before you get the fix rolled out.
Staged rollouts aren’t much good if you don’t know how your app is behaving in the wild.
While third party crash reporting tools exist, the Play Store now also does a decent job of reporting the health of your app in the Vitals section.
Here you will find any ANRs (App Not Responding), crashes and also other useful performance indicators such as rendering time and battery use.
A detailed discussion on development tools is beyond the scope of this article, but suffice to say that here at Marino we use industry standard tools and best practices to ensure that we can deliver releases in a safe, timely and agile manner. These can vary from project to project, depending on client needs, but generally include git for source control, JIRA for bug tracking and HipChat or Slack for communication.
As previously mentioned, a fast release cycle is not feasible for all projects, but we believe that if you have an app that’s in constant development it’s much better to aim for small frequent releases instead of large occasional ones. Both your developers and your customers will thank you for it!
We’re ready to start the conversation however best suits you - on the phone at
+353 (0)1 833 7392 or by email
