Workshop: Release Engineering #
In this document, we will introduce release engineering and walk through deployment strategies that reduce risk during release, plus pointers for publishing an Android app on Google Play.
Introduction #
Release engineering is the practice of getting built software to users reliably. CI (covered in the Continuous Integration workshop) keeps the Integrate and Build stages healthy; release engineering focuses on the Deploy stage: how to ship a new version without excessive downtime or risk.
This release pipeline diagram shows the four stages from code to users: Integrate (merge changes into a shared codebase), Build (compile and produce artifacts), Deploy (release to an environment or store), and Monitor (observe behaviour and feedback). Deployment strategies such as blue-green deployment and canary releases help you reduce the impact of a bad release and recover quickly if something goes wrong.
Blue-green deployment #
A common challenge when releasing is downtime during cut over: when you promote a release candidate from a testing environment to production, you often need to bring servers down, update them, and bring them back up. That window can be costly and risky.
Blue-green deployment uses two identical environments (traditionally called “blue” and “green”). One runs the current version serving user traffic; the other runs the new version. When the new version is ready, you switch traffic from the current environment to the new one (the “cut over”). There is no need to take servers down for an update—you simply point users to the environment that already has the new version. If something goes wrong with the new version, you can switch traffic back to the previous environment so it resumes serving users seamlessly. In that way, blue-green deployment also serves as a disaster recovery approach: the previously running environment remains available to take over if the new one fails.
During cut over, some setups send a portion of traffic to both environments temporarily; if the new environment fails, the old one can continue handling requests while you roll back or fix the issue.
Disaster prevention vs disaster readiness #
Disasters here means catastrophic failures of hardware or software components needed to deliver a service. There are two broad approaches:
- Disaster prevention: Design and deploy systems so that disasters cannot happen (e.g. redundancy, strict change control). The goal is to avoid failures altogether.
- Disaster readiness/recovery: Design and deploy systems so that if a disaster occurs, the system can recover quickly, ideally automatically. The goal is to minimize impact and restore service. Blue-green deployment supports this by keeping a known-good environment ready to take over.
In practice, teams often combine both: try to prevent failures, but also assume that failures will happen and design for fast recovery.
Canary releases #
Every release introduces some risk: the new version might have bugs or perform poorly. Canary releases minimize that risk by deploying to a small subset of users or traffic first (the “canary”). You then evaluate the canary—metrics, errors, user feedback—and decide whether to roll forward to more users, roll back, or alert the team for investigation. The name comes from the idea of using a canary in a coal mine: if the canary is affected, you know to act before the rest of the system is harmed.
In practice, canary release means a partial, time-limited deployment of a change, followed by an evaluation of the changed service. Production may then roll forward (expand to a bigger population), roll backwards (undo the change), or trigger an operational response (e.g. an alert or manual check). On Google Play, this pattern is available as staged rollouts: you release to a percentage of users first, then increase the percentage if the release looks healthy.
Publishing on Google Play #
This section contains information to guide you through the process of publishing the Android app that you built as the course project to Google Play. Because Google Play change the exact process quite frequently, instead of providing the exact steps (that are subject to change), I will describe the general steps and provide pointers to the official documentation which should contain the latest instructions.
You may also explore the Google Play Console’s homepage which is the entrypoint to the official documentation and tutorials.
Google Play Console: The release process is managed through the Google Play Console. New Google developers account requires a one-time registration fee. If you just want to experience the process and skip the cost for this time, you can choose to host the app on the instructor’s developer account: please send an email to the instructor with (1) the emails of all users to be added as manager of the app and (2) the (final) name of the app.
Prepare your app: Before uploading, configure your app for release. This process in general includes changing build configuration to turn off debug mode, signing the app, and testing the release build. See the Android Developers guide Publish your app for latest instructions for how to do these.
Create and set up your app in Play Console: In the console, create your app, and complete the metadata that will be shown in the Play Store: description, screenshots, graphics, content rating, etc. See Create and set up your app for the checklist.
Uploading, (more) testing, and releasing: The next step would be to upload the release build (in AAB or APK format) to Play Console. Then, you should distribute the app to a small number of testers, via the internal testing / closed testing / open testing tracks. Finally, if everything looks good, publish to production (where you can also setup staged rollouts to release to a percentage of users first). These staged testing and release steps help developers to identify and fix issues that are missed by in-house testing and arise with real-world workload (e.g., server capacity, device compatibility). See Release with confidence for more details.