Why we started riding Release Trains for our mobile applications
At Reach we provide mobile applications for over 40 of our news publications, ranging from national titles to more focused sports titles. We utilise a single codebase per platform, with customisable features and themes for each application. This means that when developing a new feature, we need to ensure that it will not just function correctly in a sandbox, but also across our fleet of applications.
To achieve this feat, we make heavy use of unit testing and automation testing, but ultimately we always need to ensure that there is a manual test function that can sign off on our releases.
As you can imagine, aligning our QA team with sporadic releases can be difficult. We need to ensure they have ample time to test a release prior to submission and guarantee we have provided details of all new functionality added, as well as inform them of any potential side effects. We also need to communicate internally with other aspects of the organisation, especially our editorial teams, about what new functionality will be available and any existing issues that have been resolved.
Ultimately, we realised we needed to rethink our release strategy to ensure a more formal and transparent approach.
All aboard the release train?
What is a Release Train?
Following Release Trains is a strategy by which large Agile teams schedule regular releases, for example every two weeks, rather than releasing when particular features are ready.
A week prior to each release a code freeze is put in place, in which all new features and bug fixes are bundled together into a release version, the version is then tested and submitted to the App Store.
Benefits
The list of benefits for utilising this approach are numerous:
- Releases are transparent and frequent: By scheduling each release, there is a heightened level of transparency for all stakeholders due to the cadence of regular releases that aren’t reliant on shiny new features.
- No last-minute additions: Utilising a code freeze date that everybody is aware of allows you to cut out any last-minute additions to a release, meaning no testing time is wasted and you can be 100% happy with the updates that are submitted.
- Better time management: Test teams are able to plan their time with more foresight; knowing when a release will be available for testing allows them to ensure they have set expectations for any other requests they receive and can devote the required time to fully testing each release.
- Features are made available when they are ready: No pressure is put on developers to rush out new features, because releases no longer rely on their work being completed. This can lead to improved code quality, tests and better implemented functionality.
Before boarding
Transitioning to Release Trains can be straightforward if you already follow a few simple requirements.
- Have good test coverage: Having good automation test coverage ensures that more regular releases do not have a negative affect on the QA teams. Ensuring they do not have to test every corner of the application every two weeks makes the transition much more seamless.
- Use feature flags: Having the ability to release code without enabling it immediately is vital to ensuring the success of the Release Train methodology. The downside to not using feature flags is increasingly large feature branches that could span months because they are not ready to be merged. They also provide the safety net of being able to disable features post release if any issues are uncovered.
- Have a willingness to change: This may be the most important requirement. Moving towards riding Release Trains requires a cultural and organisation shift in how mobile applications are developed and released. You will need the buy-in of Product Managers, QA and Developers.
Picking the right train
As with most Agile tools, the Release Train methodology should, in my opinion, be seen as a suggestion, rather than concrete blueprints. With this in mind, we discussed which aspects of this would be beneficial for our team.
Due to our iOS and Android teams being relatively small, having a release every two weeks would not be beneficial. We elected to start with a monthly release cycle, with a code freeze being put in place a week prior to the submission date. This provides us with a concrete schedule, but also enables us to ensure each release will include something meaningful. We can always look at modifying these time frames in the future.
We have also staggered our iOS and Android cycles by two weeks, so that the QA team is able to focus on a single set of releases at a time.
Internally within the iOS and Android teams we already follow Agile methodologies, building in two-week sprints, which is something that we can continue to do.
However, we made some modifications to our swimlanes within Jira to better facilitate the new approach. These changes ultimately fit more cohesively with our internal processes. We now provide clear steps between a ticket being built, reviewed by our design team, reviewed by our QA team and code reviewed, ultimately managing a ticket’s completeness via the pull request review functionality of Bitbucket, and confirming completeness via Jira.
Furthermore, we were lucky in that we already use feature flags, both in-app and via Firebase’s Remote Config, to enable and disable features within the application. Having prior knowledge of this has enabled us to have a running start in terms of including unfinished code without producing side effects.
The right destination?
So far the benefits have been positive. Our releases have been smooth and no features have been released without complete sign-off from all stakeholders.
Knowing when a release is scheduled for in advance has allowed us to communicate more effectively with our editorial teams, allowing them to promote new features and have a better understanding of timelines for when any issues they have will be resolved or new features they have requested will be included. This has also had a positive effect for our QA team who are able to schedule their time more effectively with a more robust understanding of everything that needs to be tested.
We have also been able to push out well-tested fixes more regularly, as there is no longer a question about whether there is enough in the release without feature X — if it is ready, it will be included.
As with most adopted methodologies, we will continue to tweak our implementation of it, however all signs so far look great.
