CI/CD Pipeline Checklist: Production-Ready Build, Test, Security, and Deployment Gates

Overview

A continuous integration and continuous delivery workflow is more than a sequence of build commands. It is a set of controls that turns a code change into a known artifact, moves that artifact through defined environments, and provides evidence that the release is safe enough to continue.

The right pipeline design depends on the application, risk level, team size, and deployment target. A service deployed to Kubernetes may need image scanning, manifest validation, rollout checks, and clear rollback procedures. A library may need compatibility tests, package signing, and release metadata instead. The checklist below is intended as a review framework rather than a rigid tool prescription.

For a broader foundation, compare this checklist with the practical recommendations in CI/CD Pipeline Best Practices: A Practical Guide to Faster, Safer Deployments. Treat every unchecked item as a decision to document, not automatically as a defect.

Checklist by scenario

1. Source and change validation

• Confirm that changes are traceable to a commit, pull request, ticket, or other agreed source of intent.
• Run formatting, linting, type checks, or equivalent static validation before expensive stages.
• Define which branches, tags, or events can start production-capable workflows.
• Require reviews or approvals where the change can affect security, data, infrastructure, or customer-facing behavior.
• Prevent generated files, local configuration, credentials, and unrelated changes from entering the release.
• Record the commit identifier and pipeline run identifier in the build metadata.

Fast feedback matters here. Cheap checks should fail early, while longer integration or end-to-end tests should run after the source has passed basic validation.

2. Build and dependency controls

• Build from a clean, reproducible environment rather than relying on a developer workstation.
• Pin or otherwise control important dependency and tool versions, with a deliberate update process.
• Use lockfiles or equivalent dependency resolution where the ecosystem supports them.
• Separate build-time dependencies from runtime dependencies when practical.
• Capture build logs and retain enough metadata to identify the source, builder, dependencies, and output.
• Ensure the same immutable artifact can be promoted between environments instead of rebuilt for each one.

For containerized workloads, review image construction separately from application compilation. The Dockerfile Best Practices Checklist covers practical ways to make images smaller, safer, and easier to maintain.

3. Test stages

• Run unit tests for core logic and report failures clearly.
• Use integration tests for important boundaries such as databases, queues, APIs, identity providers, and storage.
• Include contract or compatibility tests when independent services must agree on request and response behavior.
• Run end-to-end tests for critical user or business workflows, but keep their scope focused enough to remain maintainable.
• Define what test failures block promotion and what failures create an investigation task.
• Track flaky tests, quarantine them deliberately, and assign ownership for restoring reliable coverage.
• Test migrations and backward compatibility when the release changes schemas, APIs, or message formats.

A green pipeline is useful only when the checks represent meaningful risk. Review whether tests exercise failure handling, authorization boundaries, retries, timeouts, and rollback-sensitive behavior—not only the normal path.

4. Security and compliance gates

• Keep secrets out of source control, build logs, images, test fixtures, and command-line arguments where they may be exposed.
• Use the least privilege required by the pipeline identity for source access, artifact storage, deployment, and infrastructure changes.
• Scan dependencies and container images according to the risks relevant to the application.
• Validate infrastructure and deployment configuration before applying it.
• Protect production credentials and make their use auditable.
• Define how security findings are triaged, accepted, fixed, or allowed to block a release.
• Redact sensitive values from logs and failure messages.

Do not paste live credentials, private tokens, or customer data into online debugging utilities. For example, a JWT decoder can help inspect token structure, but token contents should be treated as sensitive unless they are deliberately non-production test values. The guide to safe JWT inspection provides additional context.

5. Artifact promotion

• Publish artifacts to a controlled registry or repository with clear naming and retention rules.
• Attach version, commit, build, and dependency metadata to each release candidate.
• Make artifacts immutable after publication, or clearly define how corrections are issued.
• Promote the tested artifact rather than rebuilding it with different inputs.
• Verify that the deployment system retrieves the expected digest or version.
• Define how artifacts are removed, retained, or restored during incident response.

6. Infrastructure and deployment changes

• Review infrastructure changes with the same discipline as application code.
• Generate and inspect a plan or diff before applying changes to shared environments.
• Separate environment-specific configuration from the application artifact without duplicating release logic.
• Validate Kubernetes manifests, Helm values, policies, and resource settings before deployment.
• Check database migration order, locking behavior, rollback limits, and compatibility with the previous application version.
• Use progressive delivery, staged rollout, or a maintenance window when the change warrants additional control.
• Confirm that the deployment identity can perform the required action but cannot make unrelated changes.

If a deployment produces unexpected pod, service, ingress, or rollout behavior, use the Kubernetes troubleshooting checklist to work from symptoms toward likely causes.

7. Verification, rollback, and operations

• Define a health check that tests more than process startup where possible.
• Verify logs, metrics, traces, error rates, latency, saturation, and key business signals after deployment.
• Set a specific observation period and an owner for release verification.
• Document the rollback trigger, rollback command or procedure, and any data-related limitations.
• Confirm that the previous artifact and required configuration remain available for recovery.
• Make deployment status visible to the people responsible for support and incident response.
• Link the release to dashboards, runbooks, alerts, and relevant change records.

Rollback is not always a safe undo operation. A destructive schema change, irreversible data transformation, or external side effect may require a forward fix instead. Record that constraint before release approval.

What to double-check

Before approving a production-capable pipeline, review the boundaries between stages. Ask whether a successful build can still contain an untested configuration, whether a security scan can be bypassed without visibility, and whether an approval confirms evidence or merely confirms that someone clicked a button.

• Failure behavior: Does the pipeline stop safely when a test, scan, deployment, or verification step fails?
• Permissions: Are pull-request workflows, branch builds, and production deployments using different trust levels?
• Secrets: Can a fork, untrusted contribution, dependency script, or verbose command expose protected values?
• Repeatability: Can another engineer reproduce the result from the recorded commit, configuration, and artifact?
• Environment parity: Are differences between test and production explicit, limited, and tested?
• Observability: Will the team know that a release is unhealthy before users report it?
• Recovery: Can the team restore service if the pipeline system, registry, cluster, or primary deployment path is unavailable?

Also inspect pipeline duration. Removing useful tests is not an effective optimization. Prefer parallel independent checks, caching with clear invalidation rules, selective environment setup, and early failure for inexpensive validations.

Common mistakes

• Rebuilding for every environment: This can introduce differences between the artifact that was tested and the artifact that reaches production. Build once and promote when the workflow allows it.
• Using production data in test systems: This creates privacy and security exposure and can make tests depend on uncontrolled state. Use synthetic or appropriately protected data.
• Treating approvals as a substitute for evidence: An approval should point to test results, risk notes, rollout status, and recovery plans.
• Ignoring flaky tests: Repeatedly rerunning failures can hide real regressions. Measure, own, and fix instability.
• Making rollback an afterthought: A rollback button does not solve incompatible migrations or irreversible side effects. Design recovery with the change.
• Giving the pipeline broad credentials: Excessive permissions increase the impact of a compromised script, dependency, or runner.
• Relying only on deployment success: A completed deployment does not prove that the application is serving correct traffic. Verify service health and meaningful user signals.
• Hard-coding environment assumptions: Hidden regions, URLs, feature flags, time zones, and resource limits make pipelines difficult to move and review.

When to revisit

Review this CI/CD pipeline checklist before seasonal planning cycles, major platform changes, and any release process redesign. Revisit it whenever the team changes its source-control model, build runners, artifact registry, cloud account structure, deployment target, identity provider, testing strategy, or observability stack.

A smaller review should happen after a failed deployment, security finding, rollback, prolonged incident, or recurring flaky test. Ask which pipeline control should have detected or limited the problem, then update the workflow, ownership, or runbook rather than only recording the incident.

For a practical review session, choose one recent release and trace it from commit to production. Record the artifact identifier, checks that ran, permissions used, approvals granted, deployment evidence, and recovery options. Mark every step that required manual memory or an undocumented workaround. Prioritize those gaps first, then repeat the exercise after workflows or tools change. This keeps the pipeline aligned with the system it is meant to protect.