CI/CD Release Checklist: What to Verify Before, During, and After Deployment

Overview

A production release is more than a successful build. It is a controlled change to software, infrastructure, data, configuration, and user-facing behavior. A useful deployment checklist should therefore answer five questions:

1. Is the release technically and operationally ready?
2. Who approves, deploys, observes, and communicates the change?
3. What signals determine whether the rollout continues?
4. What is the safest recovery action if the release causes harm?
5. How will the team prove that the system is healthy afterward?

The checklist below is designed to work with major CI/CD platforms, whether your team uses hosted workflows, a self-managed runner system, a GitOps controller, or a platform engineering pipeline. Adapt the names of stages, environments, approvals, and deployment protection features to your provider, but keep the decision points consistent.

For broader tool selection, see the comparison of CI/CD tools. If slow builds make releases difficult to schedule, use the CI/CD pipeline optimization checklist before adding more process.

What to track

Copyable pre-release checklist

Copy this list into a pull request, release ticket, or change record. Mark each item complete, not applicable, or blocked, and link to evidence where possible.

• Scope: The release version, commits, artifacts, configuration changes, and intended environments are identified.
• Review: Required code, infrastructure, security, and product reviews are complete.
• Build: The exact artifact to deploy was produced by the pipeline and can be traced to the reviewed source revision.
• Tests: Unit, integration, end-to-end, security, and migration tests appropriate to the change have passed.
• Dependencies: Runtime dependencies, external services, feature flags, and configuration values are compatible with the release.
• Access: The deployment identity has only the permissions needed for the release, and required secrets are available without being exposed in logs.
• Observability: Dashboards, logs, traces, alerts, and a small set of release-specific queries are ready before deployment.
• Capacity: The team has considered traffic, queue depth, database load, storage, and resource limits relevant to the change.
• Rollback: The rollback method is known, tested where practical, and compatible with the artifact, schema, and configuration changes.
• Communication: Owners, approvers, support contacts, maintenance windows, and escalation channels are recorded.

Ownership matrix

Do not assign every check to the person pressing the deploy button. A small ownership matrix prevents silent gaps:

Database migration safeguards

Database changes deserve a separate review because application rollback does not automatically reverse a schema or data change. Prefer an expand-and-contract approach when compatibility is uncertain: add the new structure first, deploy code that can work with both versions, migrate data in a controlled step, then remove the old structure only after the new path is proven.

• Take an appropriate backup or confirm the recovery point before a destructive change.
• Estimate migration duration and lock, load, or replication effects.
• Make migration steps restartable or safely repeatable where possible.
• Separate schema deployment from long-running data backfills.
• Define how to stop a migration without leaving the application unusable.
• Verify permissions, connection limits, and read/write behavior in the target environment.

For releases involving containers, also review Dockerfile and image practices. For Kubernetes workloads, pair this process with the Kubernetes deployment checklist.

Smoke-test template

Keep the first production test short and representative. Record the expected result and evidence rather than relying on an informal confirmation:

Release: [version or commit]
Environment: [production or target environment]
Timestamp: [UTC time]

1. Health endpoint responds: [pass/fail] Evidence: [link]
2. Authentication or primary access flow works: [pass/fail] Evidence: [link]
3. Critical read path works: [pass/fail] Evidence: [link]
4. Critical write or transaction path works: [pass/fail] Evidence: [link]
5. Background jobs and queues behave normally: [pass/fail] Evidence: [link]
6. Error rate and latency are within expected range: [pass/fail] Evidence: [link]
7. No release-specific alert is firing: [pass/fail] Evidence: [link]

Cadence and checkpoints

Before deployment

Complete the pre-release checklist at the approval point, not several days earlier. Reconfirm the artifact digest, configuration, target environment, migration order, feature-flag state, and on-call availability immediately before execution. A release that changed scope after approval should return to review.

During deployment

Use explicit checkpoints for each rollout stage. For a rolling, blue-green, or canary strategy, define what must be true before increasing exposure: instances are ready, health checks pass, error rates are acceptable, latency has not regressed materially, and logs show no new critical pattern. Pause automatically or manually when a stop condition is reached.

Record deployment start time, stage transitions, operator actions, alerts, and decisions. This timeline supports both incident response and later review. Deployment strategies differ in their exposure and recovery behavior; compare the options in this deployment strategy guide.

After deployment

Run the smoke-test template, then observe the service for a defined period appropriate to its traffic pattern and risk. Check application health alongside infrastructure signals: request failures, latency, saturation, queue age, dependency failures, database behavior, logs, and customer reports. Close the release only when the owner has recorded the result and any follow-up work.

Review the checklist monthly or quarterly as an operational control. Track recurring variables such as failed deployment causes, rollback frequency, time to detect, time to recover, flaky tests, migration incidents, and alerts that were missing or too noisy. The purpose is not to create a scorecard for its own sake; it is to identify where the release process needs a clearer guardrail.

How to interpret changes

A successful pipeline does not prove that a release is safe, and a failed pipeline does not always mean the application change is defective. Interpret signals in context:

• Test failures: Determine whether the failure is a real regression, an environment problem, or a flaky test. Do not normalize repeated flakes; assign them an owner and track them to resolution.
• Higher error rate: Compare the affected endpoint, tenant, region, or feature with the release scope. A localized regression may justify disabling a feature flag, while a broad failure may require rollback.
• Latency or saturation changes: Check traffic shape, cache behavior, database load, and dependency health before attributing the change solely to new code.
• Migration problems: Stop further rollout if compatibility is uncertain. Avoid an application rollback that writes data in a format an older version cannot safely read.
• Alert noise: If an alert fires without user impact, record it and improve the signal later. Do not mute it during a release without documenting an alternative detection method.

Rollback decision tree

1. Is there confirmed or probable customer impact? If no, pause and investigate while maintaining observation. If yes, continue.
2. Is the impact increasing or affecting a critical path? If yes, stop promotion immediately and reduce exposure.
3. Can a feature flag, traffic shift, or configuration change remove the failing behavior safely? If yes, use that reversible control and verify recovery.
4. Is the previous application version compatible with the current schema and data? If yes, deploy the known-good artifact. If no or uncertain, follow the migration recovery plan and involve the database owner.
5. Did rollback restore service? Verify with the same smoke tests and production signals. If not, escalate as an incident rather than repeatedly retrying deployment.

Keep rollback artifacts available and test the procedure periodically. Recovery is part of the release design, not an emergency detail to discover after a failed deployment.

When to revisit

Revisit this CI/CD release checklist on a regular monthly or quarterly cadence and after any event that changes the risk profile of delivery. A review is especially useful after a failed deployment, a rollback, a major database migration, a new deployment strategy, a change in on-call staffing, an incident, or a move between CI/CD platforms.

At each review, ask:

• Which checklist item was unclear, skipped, or difficult to verify?
• Did the pipeline and deployment protection controls enforce the intended approval path?
• Were the first useful signals available quickly enough?
• Did the rollback path work with the actual artifact, schema, and configuration?
• Which recurring failure deserves automation rather than another reminder?

Update provider-specific terms, environment names, approval rules, and links whenever the underlying platform changes. Keep the core intent stable: prove readiness, limit exposure, observe the change, and recover safely. Store the current version beside the pipeline definition or release runbook, then use it for the next release rather than treating it as documentation to read once.

Next action: choose one upcoming production release, copy the checklist into its change record, assign every owner, write the rollback trigger in plain language, and schedule the post-deployment review before deployment begins.