Patch release processes: Step by step
Context
On #20015 (closed), Delivery decided to repurpose the term "Patch release" to refer to releases that include bug and security fixes. This issue is a step-by-step process for the patch release to identify the required tooling adjustments for this rename.
There are two types of patch releases:
- A patch release targeting the versions within the maintenance policy
- A patch release targeting specific versions
Diagram
Balsamic link https://balsamiq.cloud/s6mbei5/pv056fl/r2278
Patch release for multiple versions
This will be the patch workflow used 99% of the time. Based on the Maintenance Policy for bug and security fixes, a patch release will created to release:
- Bug fixes for the current version
- Security fixes for the last three versions.
Highlights:
- Bug fixes are self-serve to the current version
- Security fixes require a manual process between Engineers and Release managers
- Due to backport requests: Bug fixes can be included in older versions.
Workflow
By the time this process starts, bug fixes are already merged and available in the stable branches.
-
⚠ Release managers start the patch release process by using the/chatops run release prepare
command - A release/task issue is created with the instructions for the release managers
-
⚠ This issue will contain the security release instructions- The template needs to be renamed #20049 (closed)
- Release managers will process security fixes by merging and deploying them to production
-
⚠ What happens if there are no security fixes?
-
- Release managers merge the backports and any other pending fix
-
⚠ After the backports are merged, the blog post will be automatically generated- The blog post needs to be updated to account for the new terminology #20052 (closed)
-
⚠ Release managers tag and publish-
⚠ Tag and publish should be smart to know if they should tag on canonical or security
-
- Release managers finalize the patch release
Patch release for a single version
Backport request authorize a version outside the policy to be patched, in this case, a patch release for that specific version will be required.
Workflow
- Release managers start the patch release process by using the
/chatops run release prepare m.n.x
command -
⚠ An issue onrelease/task
repo is open with simplified instructions- Review if this is the case.
- A blog post is automatically created on the canonical repo
- Release managers tag and publish
- Release managers merge the blog posts
- Release managers finalize the patch release
Issues identified
-
Transform the release command #20047: -
/chatops run release prepare
to create a patch issue for three versions -
/chatops run release prepare m.n.x
to create a patch issue for an exclusive version
-
-
Drop the /chatosp run release prepare --security
#20048 -
Rename the security release template to patch release #20049 (closed) -
Align the blog post to the new terminology #20052 (closed) -
Drop the security
namespace from release-tools #20050 -
Drop the security
namespace from ChatOps #20051 -
Update the blog posts with the blog post announcement #20054 (closed) -
Make release tooling smarter to update steps based on the content of the patch release #20057 -
Make release operations smarter based on the content of patch release, e.g tagging and publishing #20057 -
Review single patch release workflow #20058 (closed) -
Review the critical
workflow #19904