Skip to main content

Release Checklist

This checklist applies to every production release after the initial launch. It is a lighter process than the launch checklist, focused on safe and consistent deployment of incremental changes.

When to Use This Checklist​

Use this checklist for:

  • Feature releases and enhancements
  • Bug fix deployments
  • Dependency updates
  • Infrastructure or configuration changes that affect production

For the very first production deployment of a new product, use the Launch Checklist instead.

Pre-Release​

1. Version Bump​

  • Update the version number following semantic versioning (semver):
    • Major (X.0.0): Breaking changes or significant rewrites
    • Minor (0.X.0): New features, backward-compatible
    • Patch (0.0.X): Bug fixes and minor improvements
  • Version updated in package.json (or equivalent manifest) on the release branch
  • Git tag created matching the version (e.g., v1.3.0)

2. Changelog​

  • CHANGELOG.md updated with an entry for this version
  • Changelog entry includes:
    • Added: New features
    • Changed: Changes to existing functionality
    • Fixed: Bug fixes
    • Removed: Removed features or deprecated items
    • Security: Security-related changes
  • Changelog entry is written in plain language understandable by non-engineers

3. Pull Request to Production​

  • Release branch or main branch PR created targeting the production deployment
  • PR description includes:
    • Version number
    • Summary of changes (link to changelog entry)
    • Any special deployment instructions (migrations, environment variable changes, etc.)
    • Rollback plan
  • All CI checks passing (lint, test, build, type check)

4. Approval​

  • PR reviewed and approved by at least one engineer (standard releases)
  • PR reviewed and approved by project lead (for database migrations, infrastructure changes, or security-sensitive changes)
  • No unresolved review comments

Deployment​

5. Staging Deploy​

  • Changes deployed to the staging environment
  • Staging environment verified:
    • Application loads without errors
    • Key user flows tested (login, core feature, data submission)
    • New functionality works as expected
    • No regressions in existing functionality
  • Database migrations applied successfully on staging (if applicable)

6. Production Deploy​

  • Staging verification confirmed by the release owner
  • Production deployment triggered (manual trigger, not automatic)
  • Deployment completes without errors
  • Database migrations applied successfully on production (if applicable)

Post-Deployment​

7. Smoke Test​

Immediately after production deployment, verify the following:

  • Application is accessible at the production URL
  • Authentication works (login and logout)
  • Core feature paths function correctly
  • API endpoints return expected responses (spot-check 2--3 key endpoints)
  • No new errors appearing in error tracking (Sentry, PostHog, or equivalent)
  • No increase in response times or error rates in monitoring dashboards

8. Monitor (30 Minutes)​

  • Monitor error tracking for new exceptions for 30 minutes after deployment
  • Monitor application performance metrics (response time, CPU, memory) for anomalies
  • Monitor uptime checks for any downtime alerts
  • If any issues are detected:
    • Assess severity immediately
    • If P0/P1: initiate rollback (revert the merge commit, redeploy)
    • If P2 or lower: document the issue and create a follow-up ticket

9. Update Status​

  • Deployment status updated in the project tracking tool (mark release as deployed)
  • Release tag pushed to the remote repository (if not already done)
  • CHANGELOG.md merged to main (if changelog was updated on a release branch)

10. Notify Stakeholders​

  • Post a release notification to the project Slack channel (#project-[name]) including:
    • Version number
    • Summary of changes (2--3 bullet points)
    • Link to the full changelog
    • Any action items for the team (e.g., "verify X in production")
  • Notify the client (if applicable) through the agreed communication channel:
    • SuiteDash update for formal releases
    • Slack Connect message for minor updates
  • Notify Anchor MSP (if post-handoff) of any changes that affect operational procedures:
    • New environment variables
    • Changed monitoring thresholds
    • Updated runbook steps

Rollback Procedure​

If a production deployment causes issues that cannot be resolved quickly:

  1. Revert the merge commit on main via a new pull request
  2. Fast-track review -- one approval is sufficient for a rollback PR
  3. Deploy the reverted main to production
  4. Notify stakeholders in the project Slack channel that the release has been rolled back, with a brief explanation
  5. Create a post-mortem ticket documenting what went wrong and next steps
  6. Fix and re-release through the standard release process

Release Ownership​

RoleResponsibility
Release owner (typically the PR author)Executes the checklist, deploys, monitors, notifies
ReviewerReviews and approves the release PR
Project leadApproves high-risk releases; available for escalation during deployment

The release owner is accountable for the release from version bump through the 30-minute monitoring window. If the release owner is unavailable after deployment, they must explicitly hand off monitoring to another team member.