Skip to content

Instantly share code, notes, and snippets.

@antonagestam

antonagestam/trunk-based-release-flow.md

Created February 20, 2021 12:25
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save antonagestam/a883b12dbd1b9f31633490bf92f33aee to your computer and use it in GitHub Desktop.
Save antonagestam/a883b12dbd1b9f31633490bf92f33aee to your computer and use it in GitHub Desktop.
Download ZIP
Handling trunk-based releases with issues and tags
Raw
trunk-based-release-flow.md

Handling trunk-based release approval with issues and tags

Requesting a release

Command to create a release.

make request-release <sha>
make request-release  # default to current trunk

This creates and pushes a new tag in the form request/release/2020.02.20-01.

A workflow picks up the tag and produces an issue.

The issue contains a link to a diff to the previously deployed release.

The issue description is expected to be updated to contain the release description, with a list of all changes. The full description of the issue will be "burnt-in" as the release description later on.

...

Having pondered, I'm coming to the conclusion that it's unnecessary to have an explicit release request command (except, it's probably good for creating fix-releases). We could just have a trigger on trunk receiving new commits and update a "long-running" release issue, or a create a new one if it doesn't exist already. This task would also update the name of the release to the current date automatically.

This means there will always be an open release issue when there are unreleased commits on trunk.

That would also mean we wouldn't need special release-request-tags.

Approving releases

Releases are approved by reviewers posting a comment in the form /approve <commit sha> on the release issue. The release creation flow listens for comments on the issue and counts the number of comments containing the /approve <sha> with the sha the release tag is pointing to.

Reviewers can withdraw their approval by removing their approving comment. (easier than introducing a disapprove-command and having to parse across messages).

The reviewers that approved the release will be "burnt-in" in the release description later on in the flow.

The release issue description can contain a helptext with available commands. If we put it after a "tagging" html comment, that can be used to strip it from the resulting description burnt-in on the release (eg description.split("<!--marker:ignore-below-->")[0]):

- Update email copy

<!--marker:ignore-below-->
<!-- Text below will not appear on the release -->
Commands:
- `/approve <sha>`
- `/deploy`

Creating a release

When the release has been validated and has received the required number of approvals, the /deploy command can be issued. The command validates that all required checks have passed and that the required number of approvals have been received. It can also check that there aren't any hot-release-issues open and deny deploying on that basis.

If all checks pass, a release is built and published and deployment workflows are triggered. A release tag is created and the release page receives a "burnt-in" description of the release from the issue together with annotations for "Approved by: x, y" and "Triggered by: z".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment