Release checklist

A preview of how this template lays out — the boards, their custom workflow states, and where the sample issues land. WIP caps show a badge.

• Release v0.14

  Parent issue; sub-issues cover changelog, migration check, smoke tests, and announcement.

  P15pt

• Draft v0.14 changelog from merged PRs

  P22pt

• Run production smoke suite

  P11pt

These rules aren't created when you apply the template — they're recipes you can wire up in Settings → Automations once your board exists.

• When

  Release issue moves to 'Rolling out'

  Then

  Post the release notes to #releases and the changelog

• When

  All sub-issues completed

  Then

  Mark the parent release 'Done' and start the next one

This template is a runbook wearing a board's clothes. The parent issue is the release; the sub-issues are the steps; the parent is done when the children are. That structure exists because release checklists fail in a specific way — they live in a document, someone copies it, and the copy diverges until step four means something different to each person who runs it. A checklist that is instantiated as real, assignable, timestamped work does not drift the same way.

1. 1.Instantiate the whole checklist at Planned

   Create the release parent and expand the full sub-issue tree before the cut, not as you go. Seeing all fifteen steps at once is what surfaces the one that needs a two-day lead time — a partner notification, a store review, a scheduled maintenance window — while there is still time to start it.

2. 2.Make Cutting a hard boundary

   Once the release is cut, the branch is closed. Anything that arrives after goes into the next one unless it is a genuine release blocker, and 'genuine release blocker' should be a decision someone named makes, not a mood. Teams that let one more thing in reliably discover that one more thing is unbounded.

3. 3.Treat Staging QA as a gate with a written pass

   Nothing reaches Rolling out without a recorded pass on the staging suite. Record what was tested, not just that it was — 'smoke passed' with no list is unfalsifiable, and six weeks later when you are asking whether a regression was covered, you will need to know.

4. 4.Roll out in stages and watch the first one

   Rolling out is a state, not an instant. Ship to a fraction, watch your error rates and key flows, then widen. The rollout step should name what you are watching and what value triggers a rollback, decided in advance — deciding that while an incident is starting reliably produces the wrong answer.

5. 5.Draft the notes from what actually merged

   The changelog step should be generated from merged work rather than written from memory, and it should be drafted during Cutting, not after rollout. Writing release notes after the fact is how they get thin, late, or skipped entirely.

This board encodes one opinion about how the work should run. Here is where that opinion is wrong and something else fits better.

• You deploy continuously to production. If you ship twenty times a day, a release parent per deploy is nonsense — your checklist should be automated gates in the pipeline, and the human ritual should be reserved for genuine version boundaries if you even have them.
• Your checklist is entirely automatable. If every step is a command, it belongs in CI, not on a board. Manual tracking of automatable steps is how a checklist becomes a formality that people tick without doing.
• Releases need formal change approval. Regulated environments needing a change advisory board, recorded approvals, and an auditable trail should use a change-management process with real approval gates. A board column is not an approval record.
• You ship once a year. At that cadence the checklist is stale by the time you need it, and you will be rewriting it from scratch anyway. Write the runbook fresh each time and treat the last one as reference.

Honest comparisons, including where the other tool wins. Planoda is pre-launch, so nothing below is a benchmark — it is a description of how each product approaches this job.

• GitHub Actions and CI pipelines

  The strongest version of a release checklist is one that cannot be skipped because it is a pipeline stage. Everything mechanical — tests, builds, artifact signing, staged rollout, smoke checks — belongs there. This board is for the steps that need a human decision: has support been briefed, is the changelog accurate, are we happy to widen.

  Where GitHub Actions and CI pipelines is better: For anything a machine can verify, CI is better without qualification. It cannot be forgotten, it is auditable, and it runs identically every time. Use this board only for the residue.

• Jira

  Jira's release and version model tracks which issues shipped in which version and generates release notes from that, which is genuinely useful traceability. This template tracks the process of releasing rather than the contents of the release, and the two are complementary.

  Where Jira is better: For 'which version contains this fix' — a question support and customers ask constantly — Jira's version tracking answers it natively in a way a checklist board does not.

• Notion

  A Notion release runbook page duplicated per release is the common lightweight approach, and the writing is better: the page can explain why a step exists, which a card title cannot. The cost is that the copy diverges from the master and nobody can tell you who did step four or when.

  Where Notion is better: For the runbook's explanatory prose — the rationale, the escalation contacts, the rollback reasoning — a written page is better than a set of cards, and the best setup links one from the other.