Release Checklist: Pre-Deploy Control List in Alios

Release Checklist: Pre-Deploy Control List in Alios

Friday afternoon. The release is ready, everyone wants to go home. Under the pressure of "let's get this out quickly," one step gets skipped. Something critical breaks in production. Weekend crisis mode.

This scenario falls into the "could have been prevented with more care" category. But care alone isn't enough. The human brain skips steps under pressure and fatigue — that's a cognitive reality. The solution isn't to be more careful. It's to put the skippable steps into the system.

A release checklist exists for this reason. When pilots use a pre-flight checklist it doesn't mean they don't know how to fly. It means critical steps need to be tied to a system, not to memory.

What Gets Forgotten During a Release?

Steps skipped during a release generally fall into three categories.

Technical checks: Going live without testing in staging. Environment variables not updated for production. Database migration not run. No rollback plan in place.

Communication steps: No advance notification sent to customers. The team wasn't informed about the go-live. Changelog wasn't updated. The support team wasn't briefed on the new feature.

Verification steps: No smoke test after going live. Monitoring alerts not checked. No plan for the first 24 hours of monitoring.

Each of these steps looks small on its own. But when several are skipped at the same time, a production incident becomes inevitable.

Copyable Release Checklist in Alios

In Alios, a release checklist gets built once and copied before every release. Copying works like this: the template node gets copied, the title gets updated to "[Version] — Release — [Date]," an owner gets assigned. Every item on the list is already waiting.

This approach has two benefits: no step gets skipped because the list is standardized, and the history of every release stays in the archive because the node is never deleted.

The template below can be used directly in Alios.

📁 RELEASE [Version] — [Date]
Owner: [Release owner]
Planned go-live: [Date / Time]
Environment: Production
Release notes link: [If available]

PRE-RELEASE — 48 Hours Before

- [ ] All feature branches merged to main
- [ ] Conflicts resolved, CI/CD pipeline green
- [ ] Deployed to staging environment
- [ ] Database migration scripts ready and tested
- [ ] Environment variable changes documented
- [ ] Rollback plan written — steps to revert
- [ ] Release notes draft prepared
- [ ] Dependent services or third-party integrations
      checked — any breaking changes?

STAGING TEST — 24 Hours Before

- [ ] Smoke test complete — core flows working
- [ ] Critical user scenarios tested
      [ ] Registration / Login flow
      [ ] Payment flow (if applicable)
      [ ] Core CRUD operations
      [ ] Notification flow (if applicable)
- [ ] Mobile view checked (if applicable)
- [ ] No performance regression — load times compared
- [ ] Acceptance criteria for new features met in staging
- [ ] Bugs fixed in this release verified in staging
- [ ] QA approval: [Name] — [Date]

COMMUNICATION — 24 Hours Before

- [ ] Team informed of go-live date and time
- [ ] Support team briefed on new features
- [ ] Planned downtime (if any) communicated to customers
- [ ] Customer announcement prepared (new feature)
      Send date: [Date]
- [ ] Social media or blog content ready (if applicable)

PRE-DEPLOY — 1 Hour Before Go-Live

- [ ] Staging checked one final time — any last changes?
- [ ] Database backup taken
- [ ] Environment variables updated for production
      [ ] API keys
      [ ] Database connection strings
      [ ] Feature flags
      [ ] Third-party service configurations
- [ ] Monitoring and alerting active — baseline checked
- [ ] Rollback procedure shared with team
- [ ] On-call person identified — first 2 hours post-release
- [ ] "Deploy starting" communicated to team

DEPLOY — Go-Live

- [ ] Deploy command executed
- [ ] Pipeline completed successfully
- [ ] Database migration run and verified
- [ ] Application up, health check green
- [ ] "Deploy complete" communicated to team — time: [Time]

POST-DEPLOY — First 30 Minutes

- [ ] Production smoke test done
      [ ] Core flows working
      [ ] New features working
      [ ] Areas affected by fixed bugs checked
- [ ] Error rate checked — no abnormal increase
- [ ] Response time checked — no regression
- [ ] Logs reviewed — no unexpected errors
- [ ] Monitoring alert baseline back to normal
- [ ] "Release successful" communicated to team

RELEASE CLOSE — First 24 Hours

- [ ] Changelog updated and published
- [ ] Customer announcement sent (if planned)
- [ ] Release notes published
- [ ] Support team notified "live"
- [ ] 24-hour monitoring complete — no anomalies
- [ ] Release node closed as "Done"
- [ ] Release retrospective note added:
      What went well: [1-2 sentences]
      What was hard: [1-2 sentences]
      What changes next release: [1 item]

Customizing the Checklist for Your Team

The template above is a general starting point. Every team needs to customize it for their own stack and process.

Items that can be removed: If there's no mobile app, mobile checks come out. For releases without planned downtime, customer notification isn't mandatory. For small hotfixes, the 48-hour preparation window isn't needed.

Items that can be added: For Kubernetes environments, pod health checks get added. For multi-region deployments, separate check lines for each region. For A/B test launches, feature flag configuration.

Stack-specific items:

For AWS:

- [ ] CloudFormation stack updated
- [ ] S3 bucket policies checked
- [ ] CloudFront cache invalidation done

For Kubernetes:

- [ ] Deployment manifest updated
- [ ] Resource limits checked
- [ ] Pods in Healthy state

For database migrations:

- [ ] Migration is idempotent — safe to run twice
- [ ] Rollback migration prepared
- [ ] Migration duration estimated — is the
      maintenance window sufficient?

Emergency Release Protocol

For hotfixes or critical bug fixes, the full checklist may be too long. A shortened version for these situations:

📌 EMERGENCY RELEASE — [Description]

REQUIRED CHECKS:
- [ ] Fix tested in staging — bug no longer reproducible
- [ ] Not breaking anything else — quick regression test
- [ ] Database backup taken (if migration involved)
- [ ] Rollback steps are clear
- [ ] Team informed

POST-DEPLOY:
- [ ] Verified in production
- [ ] Error rate normal
- [ ] Full checklist to be completed retroactively: [Date]

The emergency release protocol doesn't mean "we're skipping the full checklist." It means "we're doing the critical items now, and we'll document the rest."

Final Thought

A release checklist for pre-deploy control works like a pilot's pre-flight checklist: it's used by people who know how to fly, because critical steps need to be tied to a system, not to memory.

Keeping this checklist as a copyable node in Alios guarantees two things: every release goes out to the same standard, and the history of every release stays in the archive.

The step forgotten under Friday afternoon pressure doesn't turn into a production incident. Because the step doesn't get forgotten — the list is there.