Releases

Process

Our releases follow semver principles: machines should take care of versioning and all releases should follow a consistent pattern and workflow. Sentimental versioning is to be avoided!

We have a pre-built configuration that we use across our projects to standardise versioning and releases, and adapt this based on the needs of the project.

Here’s a simplified illustration of how the release and versioning process works for a mobile application as it approaches an initial public release:

Release Process diagram

Release types

Alpha (Internal)

We produce these as internal previews throughout the development process. Their versioning sequence is independent of Production/Beta releases, and they are run in a unique environment. This allows us to share builds with internal tester groups (including clients, as needed) for QA and exploratory testing as frequently as necessary, without affecting the Production release cycle:

  • For mobile projects, this will typically be as a nightly release to TestFlight or Google Play if there have been releasable changes. By releasing once a day at most, we achieve visibility into development progress without overwhelming testers with new builds.
  • For web projects, a similar approach applies, but releases are deployed to a staging server (e.g. a Netlify or AWS instance) for previewing. These releases are more frequent, since the user does not need to perform the additional step of downloading a mobile app.

Where these Alpha releases interact with an API, database or external service, each of these interactions will almost always be configured to hit a unique Alpha environment. This helps to ensure that Alpha testing does not contaminate Production environment data.

Production (and Beta)

An additional test lane is configured for Production and Beta releases. For a mobile app, the same build artefact will be used for both.

  1. The build is generated
  2. The build is released to the mobile testing platform (e.g. TestFlight for an iOS app Beta)
  3. QA testing is performed, using dummy testing accounts where applicable.
  4. Once all is approved, the same build will be promoted to further test groups, and ultimately to a Production release.

This technique enables us to perform a controlled, closed Beta release and test this thoroughly, before the build is promoted to Production. That ensures that the build has been tested in the Production environment prior to users being able to access it.

Production builds are automatically generated/compiled, but by necessity, the process for publishing a release to Production usually involves at least 1 manual step, since every client will have their own set of protocols that they want to complete prior to a real-world release. This will typically include acceptance testing, final V&V, and executing the manual tests in the Test Plan. We also want to eliminate the possibility of a release accidentally being deployed to Production.

And beyond

Beyond this point, the process will diverge based on the type (mobile, web or hardware) and nature of the product. Since the scripted release configuration is written in code, the process can be modified to meet future release needs.