How to Build a Pre-Release Checklist Generator

Release day checklists are a solved problem in theory. In practice, every team either has a stale Google Doc that nobody updates, or no checklist at all — just a shared anxiety that someone might have forgotten something. The fix is to generate the checklist automatically from the systems that already know the project’s state: your CI pipeline, your bug tracker, and your changelog. The checklist is never out of date because it is never manually maintained.

Designing the Template

A release checklist has two kinds of items: static items that apply to every release (e.g., “verify the build compiles on all platforms”) and dynamic items that change based on what’s in the release (e.g., “review these 4 open critical bugs”). The template defines both.

Static sections are straightforward. They are the same every time and represent your team’s institutional knowledge about what can go wrong. Common static sections include: build verification, smoke test on each platform, changelog accuracy, store page update, analytics event verification, and rollback plan confirmation.

Dynamic sections use placeholder tokens that the generator replaces with live data. For example, a {{open_critical_bugs}} token expands into a list of bug titles with links. A {{ci_status}} token expands into the pass/fail result of the latest CI run. A {{changed_files_count}} token shows how many files changed since the last tagged release.

# checklist_template.yaml
title: "Release Checklist — v{{version}}"
date: "{{generated_date}}"

sections:
  - name: "Build Verification"
    owner: "{{build_engineer}}"
    items:
      - "CI pipeline passed: {{ci_status}}"
      - "Build size within budget: {{build_size_mb}} MB"
      - "No compiler warnings in release config"
      - "Smoke test passed on all target platforms"

  - name: "Open Critical Bugs"
    owner: "{{qa_lead}}"
    condition: "{{open_critical_count}} > 0"
    items:
      "{{#open_critical_bugs}}"
      - "[ ] Review: {{title}} ({{url}})"
      "{{/open_critical_bugs}}"

  - name: "Changelog"
    owner: "{{product_manager}}"
    items:
      - "Changelog entries match merged PRs"
      - "No internal-only entries visible"
      - "Version number correct: v{{version}}"

The condition field makes sections conditional. If there are no open critical bugs, that section is omitted entirely. If the release doesn’t target console, the console certification section disappears. The checklist adapts to the release.

Connecting to Data Sources

The generator script pulls data from three sources. First, your CI pipeline: query the CI API (GitHub Actions, GitLab CI, Jenkins) for the latest build status on the release branch. Check whether all required checks passed and whether the build artifacts are available. Second, your bug tracker: query for open bugs with critical or blocker severity assigned to the current milestone. If you use Bugnet, the API endpoint /api/projects/{slug}/bugs?status=open&priority=critical returns exactly what you need. Third, your source control: diff the release branch against the last tagged release to count changed files, identify new assets, and flag any files that require special review (e.g., migration scripts, config changes).

# generate_checklist.py
import yaml, requests, subprocess, datetime

def get_ci_status(branch):
    resp = requests.get(
        f"https://api.github.com/repos/OWNER/REPO/"
        f"actions/runs?branch={branch}&status=completed",
        headers={"Authorization": f"token {GH_TOKEN}"}
    )
    runs = resp.json()["workflow_runs"]
    return "PASSED" if runs[0]["conclusion"] == "success" \
        else "FAILED"

def get_open_critical_bugs(project_slug):
    resp = requests.get(
        f"https://app.bugnet.io/api/projects/"
        f"{project_slug}/bugs?status=open&priority=critical",
        headers={"Authorization": f"Bearer {BUGNET_TOKEN}"}
    )
    return resp.json()["data"]

def get_changed_files(last_tag):
    result = subprocess.run(
        ["git", "diff", "--name-only", f"{last_tag}..HEAD"],
        capture_output=True, text=True
    )
    return result.stdout.strip().split("\n")

Assemble the data, render the template, and output the checklist as a Markdown file, a Confluence page, a Notion document, or a GitHub issue — whatever format your team actually reads. The format matters less than the automation: the checklist should appear without anyone having to remember to create it.

The Sign-Off Workflow

Each section of the checklist has an owner. The owner reviews the items, verifies them, and signs off by adding their name and a timestamp. The release cannot ship until every section is signed off. This creates accountability — if the build ships with a known critical bug, the sign-off record shows who approved it and when.

For small teams, a comment on the checklist document is enough. For larger teams, use a tool with audit logging. GitHub issue checkboxes work well: each checkbox is a checklist item, and the person who checks it is recorded in the issue timeline. For more formal processes, tools like Release or LaunchDarkly provide sign-off workflows with approval chains.

“A checklist without sign-offs is a wish list. Sign-offs turn it into a contract between the team and the release.”

Conditional Sections

Not every release needs every section. A hotfix that changes one file doesn’t need a full localization review. A release that doesn’t ship to console doesn’t need console certification items. Use conditions in your template to include or exclude sections based on the release context.

Common conditions: include the “Localization” section only if translation files changed. Include the “Database Migration” section only if migration scripts are in the diff. Include the “Console Certification” section only if the release branch name contains a console platform identifier. Include the “Performance Review” section only if the build size increased by more than 10% or FPS benchmarks regressed.

This keeps the checklist focused. A five-item hotfix checklist gets completed. A forty-item checklist gets skimmed and rubber-stamped.

Archiving and Learning

Save every generated checklist with the release version number. After a few releases, review the archive. Look for patterns: which sections consistently have issues? Which items are always checked without thought (remove them)? Which items have caught real problems (highlight them)? The checklist should evolve based on what actually goes wrong, not what theoretically could go wrong.

If a post-mortem reveals a release issue that the checklist didn’t catch, add a new item to the template immediately. If an item hasn’t caught anything in ten releases, remove it. A lean, battle-tested checklist is more effective than a comprehensive one that nobody reads carefully.

Related Issues

For automated build-size tracking that feeds into the checklist, see How to Track and Reduce Game Download Size. For managing the surge of bug reports during the release itself, check How to Handle Player Reports During Live Events.

The best checklist is the one that generates itself and forces you to sign your name next to each item.