11 — DevOps and CI/CD Checklist#

Verify repeatable builds, trusted deployment artifacts, controlled infrastructure changes, safe rollout and rollback, and accountable software delivery. This checklist focuses on delivery systems; evaluate detailed functional tests, security, reliability, observability, and launch procedures in their own checklists as well.

Scope: Shared / cross-cutting. This file is one part of the 11_DevOps_and_CI_CD.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

• Project / product:
• Release / version / environment:
• Scope and applicable jurisdictions / markets:
• CI/CD platform / infrastructure tooling:
• Reviewer / owner:
• Review date:
• Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

1. Make a project-specific copy and leave the repository's shared template unchecked.
2. Verify each applicable item with pipeline definitions, build records, environment configuration, release artifacts, logs, or observed deployment results. Document failures, accepted risks, and N/A rationales in project-specific review notes/issues keyed by OPS ID; do not add evidence tables to this template.
3. Interpret platform-specific checks according to the tools actually used. GitHub Actions, Terraform, Kubernetes, SLSA, and specific rollout strategies are examples, not universal mandates.
4. Evaluate ## API Checks and ## Frontend Checks separately when present; document why either does not apply to a headless or non-API service.
5. Review delivery policy after consequential changes to build systems, access rules, infrastructure providers, release methods, or compliance requirements. Passing this checklist is not proof of security certification.

Build and integration workflow#

• OPS-002 Ensure supported build commands execute in an isolated, repeatable environment without depending on a developer's workstation state.
• OPS-003 Pin language runtimes, compilers, major build tools, and package-manager versions sufficiently to reproduce release builds.
• OPS-004 Use dependency lockfiles or an equivalent deterministic resolution method where supported and enforce their consistency in CI.
• OPS-005 Require the relevant compilation, lint, format, type, and unit-test checks to pass before accepting release candidates.
• OPS-006 Run integration and contract checks against representative dependencies or controlled test doubles, according to risk.
• OPS-008 Keep fast feedback checks early in pipelines and reserve slower end-to-end or nonfunctional jobs for appropriate stages.
• OPS-009 Capture structured test reports, logs, and failed-job diagnostics with enough context to reproduce failures.
• OPS-010 Record flaky, quarantined, and intermittently failing tests with owners, expiry or remediation plans, and visibility in CI.
• OPS-011 Ensure build artifacts have immutable version identifiers, such as source commit, package version, and digest.
• OPS-012 Build a release artifact once and promote the same artifact through later environments rather than rebuilding it with untracked changes.
• OPS-013 Publish artifacts to an access-controlled registry or repository with retention and deletion policies.
• OPS-014 Generate software bills of materials or comparable dependency inventories when required by project risk or supply-chain policy.
• OPS-015 Generate and verify build provenance or artifact attestations to the organization's selected SLSA assurance target where appropriate.
• OPS-016 Restrict workflow permissions, protect build signing keys, and avoid long-lived credentials in CI wherever a scoped alternative exists.
• OPS-017 Pin third-party CI actions, tasks, and images to trustworthy immutable versions or digests where possible.
• OPS-018 Keep untrusted contributions, external code, and test data from receiving privileged tokens or modifying trusted release artifacts.
• OPS-019 Use caching without allowing stale, poisoned, or cross-trust-boundary caches to change the correctness of release builds.
• OPS-020 Define parallel-job, cancellation, retry, and concurrency policies so obsolete runs cannot race or replace a newer release.

Deployment and rollback#

• OPS-047 Protect production deployments against unintended triggers and concurrent or superseded runs.

• OPS-053 Use expand/migrate/contract or another safe strategy for changes that cannot be instantly reverted.

• OPS-054 Identify irreversible migrations or external side effects and plan forward fixes or compensating actions instead of assuming rollback is possible.

• OPS-055 Test the documented rollback or roll-forward procedure for representative failure cases and required time limits.

• OPS-056 Define explicit go/no-go metrics, alert thresholds, release observation windows, and who may halt a rollout.

• OPS-058 Retain the prior known-good artifact and required configuration long enough for authorized recovery.

• OPS-059 Verify that traffic shifts, feature flag changes, and rollback actions are auditable and bounded in scope.

• OPS-061 Notify affected teams and downstream consumers of scheduled downtime or disruptive migrations where applicable.

Delivery governance#

• OPS-065 Protect the release source and workflow definitions with repository access rules appropriate to project risk.
• OPS-068 Use documented exception handling for blocked pipelines, bypass requests, and emergency releases with appropriate authorization.
• OPS-069 Separate duties for high-risk operations if mandated by contracts, regulation, or organizational policy.
• OPS-070 Maintain an on-call or escalation path for failed pipelines, unsuccessful deployments, and critical release regressions.
• OPS-073 Check that improvements in delivery speed are not achieved by suppressing quality, security, or customer-impact signals.
• OPS-076 Ensure emergency rollback and production access procedures can be executed when the main automation platform is unavailable.
• OPS-077 Publish release notes or change summaries relevant to operators, support teams, and affected consumers.
• OPS-080 Reassess delivery controls after major changes to service architecture, vendor platforms, compliance scope, or release frequency.

Release gate#

• The intended source revision builds successfully through a repeatable, reviewed pipeline and produces an identifiable immutable release artifact.
• Required test, contract, security, and infrastructure checks pass or have risk-appropriate and explicitly authorized exceptions.
• Production identities, secrets, environment settings, and deployment permissions are scoped, protected, and reviewed for the actual target.
• Deployment sequencing, health/readiness checks, compatibility constraints, and recovery or rollback procedures are documented and have been validated as appropriate to risk.
• API/frontend consumers, environment dependencies, and data migrations are compatible with the rollout, or an approved coordination plan prevents disruption.
• Release owners have observable go/no-go criteria, post-deployment checks, escalation paths, and project-specific records of the release decision.

Domain-specific approval rule: Block promotion when the artifact's identity or origin is unknown, mandatory pipeline gates fail without approval, production secrets/permissions are exposed, material backward-compatibility risks are unresolved, or a failed rollout cannot be safely stopped or recovered without an accepted and documented contingency.

Trusted references and scope#

The following primary sources inform the verification questions above. Their platform-specific recommendations are conditional on the actual environment and risk profile; they are not claims that every project must use a particular provider or tooling.

• DORA — Continuous delivery — delivery automation, automated testing, and smaller reversible changes.
• DORA — Test automation — pipeline quality gates and rapid feedback.
• DORA — Loosely coupled teams — independent deployment and contract compatibility.
• AWS — DevOps guidance: Continuous integration — repeatable builds and integration practices.
• AWS — DevOps guidance: Continuous delivery indicators — trusted artifacts, deployment automation, and quality assurance.
• GitHub Docs — Security for GitHub Actions — workflow hardening, pinned actions, artifact attestations.
• GitHub Docs — Security hardening your deployments — OIDC-based cloud authentication and deployment credentials.
• GitHub Docs — Deployments and environments — protected environments and conditional approval controls.
• SLSA Specification v1.2 — software supply-chain assurance and build provenance; assurance levels are optional risk-based targets.
• HashiCorp Terraform — State — infrastructure state, locking, and access controls when Terraform is used.
• Kubernetes — Liveness, Readiness, and Startup Probes — safe workload health and traffic readiness when Kubernetes is used.
• OpenTelemetry — Signals — logs, metrics, and traces for release verification.

Applicability: A small static website, an API service, a regulated platform, and a distributed system have different release risks. Adapt the controls accordingly. GitHub environment protection, DORA capabilities, SLSA levels, Terraform remote state, and Kubernetes probes do not apply unchanged to every project.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

• Test focus: pipeline definitions, IaC policy, build artifacts, and deploy smoke checks; include shared/cross-team controls where applicable.
• Cross-stack: actionlint + Checkov + Trivy.
• Python: pytest-testinfra + pytest; for pytest-based suites, run python -m pytest -q.
• TypeScript: Testcontainers + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
• JavaScript: Testcontainers + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
• Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

• ci-cd-and-automation — Review automated quality gates and deployment flows (addyosmani/agent-skills, 116,378 repo stars).
• github-actions-templates — Inspect GitHub Actions where used (wshobson/agents, 42,437 repo stars).
• agentic-actions-auditor — Assess workflow permission and supply-chain risks (trailofbits/skills, 8,150 repo stars).

How to check: In a project-specific copy, have the agent audit the shared / cross-cutting scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.