This post was originally published on mobile.blog.
A new great feature, an important bug fix, a UI improvement, a subtle but effective change; whenever the latest development is complete, the next step is to ship it to users.
As developers, we want to deliver improvements quickly, but we have to strike a balance. We like to release bug fixes as soon as possible, but we also want to avoid annoying users with too-frequent updates.
With the WordPress mobile apps (and now also WooCommerce), we’ve found our sweet spot with a two week heartbeat. Every two weeks, we freeze the codebase, stabilize the build with help from our testing community, and then release it on the app stores.
The process
The release train passes every other week and picks up every bug fix and feature completed up to that day. To be ready for release, a new version of the app must fulfill a set of minimum requirements:
- A stable build with no unverified warnings.
- The build passes all the automated tests run by continuous integration system.
- New strings have been submitted to our community translation tool, so we can support as many languages as possible with each update.
- Every new feature has been properly tested and the whole application has been tested against regressions.
- A proper app store setup is available to showcase the relevant changes (release notes, screenshots, metadata).
Continuously meeting every item in this checklist is only possible with good development practices in place. We rely on strict version control, a GitFlow branching model, and a community of testers as we ship each iteration.
Strict version control
The apps’ source code is on GitHub and every piece of new code is reviewed by at least one developer. Additionally, a continuous integration (CI) system checks the style and the build on every pull request (PR).
GitFlow branching model
We use the GitFlow branching model to manage bug fixes and feature development. It has some useful characteristics:
- Parallel development: GitFlow makes parallel development straightforward by isolating development of new features from finished work. New development is done in feature branches, and is only merged back into the main body of code when the developers are satisfied that the code is ready for release.
- Collaboration: feature branches also make it less difficult for two or more developers to collaborate on the same feature, because each feature branch is a sandbox where the only changes are the changes necessary to get the new feature working. That makes it very easy to see and follow what each collaborator is doing.
- Release staging area: as new changes as ready, they get merged back into the develop branch, which is a staging area for code that hasn’t been released. So when the next release is branched off of develop, it will automatically contain all of the new features that have been finished.
- Support for emergency hotfixes: this model also provides support for emergency fixes via tags. Hotfix branches can be made from a tagged release and used to make an emergency change, safe in the knowledge that the hotfix will only contain the emergency fix. There’s no risk new development is accidentally merged at the same time.
A community of Beta Testers
We have a community of beta testers that receive the new version in advance and send us feedback. This is a very important addition to our own internal testing.
Release schedule
A full release cycle can be divided in three stages:
Code Freeze
On day one of the release cycle, we make the cut: anything not in the development branch will not be included in this release.
Following GitFlow, a new release branch is created from the development branch. From now to the actual release date, this branch will only receive the changes required to finalize and stabilize the new version: things like translations for new strings, and bug fixes based on beta tester feedback.
After the cut, we run a script that picks up every new string added in the main application and in any dependencies and sends them to GlotPress, the WordPress community’s open source translation tool.
The last step on day one is to create a beta release and to distribute it to beta testers.
Stabilization
After code freeze, there are 12 days dedicated to stabilizing the release.
This is an iterative process: we start gathering feedback from beta users and, if there are any bugs, we correct them and push a new version out. This is repeated until every known issue is fixed.
In the meantime everyone on the team can keep developing new features and merging them into the development branch without being worried about affecting the current release.
Additionally, during this period the translators add translation for the new or updated strings.
Submission and Release
Ideally, by day 14 we are confident that we have a solid version to release to all users.
We download the updated localized strings and create a new build that we push to the app stores.
If needed, we generate new screenshots and update the app description and other metadata.
We always release with a phased rollout, starting to deploy the new version to a small percentage of users and monitoring to ensure that no new crashes are present.
On the same day, we start the process all over again, going back to Day 1 and cutting a new release from the main Git branch.
Release management
As you can imagine, keeping the ball rolling requires some coordination. We have people dedicated to managing and monitoring releases. They are in charge of making sure all the steps are done at the correct time and that every piece of user feedback is acted upon.
We have also built a set of scripts that help simplify the release process. We are continuously improving them as we aim to automate the whole process and provide solid release infrastructure that can be shared by all our apps.
After following this process for some time now, we find that it fits our goals well. It allows us to continuously improve our apps and consistently ship new features and reliability enhancements without annoying our users with too-frequent updates. It allows us to work with a deadline in mind, without forcing us to ship half-baked features, because the next version is not too far in the future. And it allows the community of beta testers and translators to contribute to every new version. We can’t thank them enough for their dedicated support!
The WordPress and WooCommerce apps are fully open source, so if you’re interested you can follow the release process on GitHub.
Also, if you want to help us make our mobile releases better, you can join our beta programs for iOS and Android.