30 — 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: Backend / API-specific. This file is one part of the 30_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-001 Define which source changes trigger build, test, package, and deployment workflows, including changes to shared libraries and infrastructure.
• OPS-007 Fail the pipeline on required quality gates instead of logging failures while reporting success.
• OPS-021 Document how developers run key CI checks locally and how pipeline changes are reviewed and tested.
• OPS-022 Review pipeline duration, failure causes, and feedback quality regularly, with tracked improvements.

Infrastructure and environments#

• OPS-024 Describe infrastructure in version-controlled, reviewable configuration or infrastructure-as-code wherever suitable.
• OPS-025 Use code review and an explicit plan/diff before applying material infrastructure changes.
• OPS-026 Protect infrastructure state with appropriate remote access controls, locking, backups, and encryption where the chosen tool requires it.
• OPS-028 Use short-lived, least-privilege deployment identities and segregate production permissions from lower environments.
• OPS-031 Detect infrastructure drift between declared and deployed state and record its resolution.
• OPS-032 Ensure container base images, runtime environments, and third-party dependencies follow an update and patching policy.
• OPS-033 Scan infrastructure definitions or deploy manifests for high-risk misconfigurations using relevant tools.
• OPS-035 Define network boundaries, ingress/egress rules, identity dependencies, and necessary service connectivity.
• OPS-040 Protect environment-specific domains, DNS, TLS certificates, CDN settings, and routing configuration through a controlled process.
• OPS-041 Document how deployment pipelines access protected environments, including human approvals where law, risk, or policy requires them.
• OPS-042 Set environment cost and retention boundaries, and periodically remove abandoned infrastructure.
• OPS-023 Inventory environments and their purpose, ownership, region, critical services, and lifecycle.
• OPS-027 Keep provider credentials, tokens, certificates, and encryption keys out of source, build output, and shared job logs.
• OPS-029 Separate development, test, staging, and production data and access according to risk, with no accidental production-data copies.
• OPS-030 Manage configuration differences deliberately, documenting feature flags, endpoints, quotas, and secret references by environment.
• OPS-034 Set capacity and resource requests, limits, autoscaling policy, and quota expectations for critical workloads when applicable.
• OPS-036 Verify environment provisioning and teardown are repeatable and do not leave unmanaged resources or credentials.
• OPS-037 Ensure managed databases, caches, queues, and storage have documented ownership and configuration baselines.
• OPS-038 Define lifecycle, startup, readiness, and liveness behavior for workloads so traffic is not sent to unready instances.
• OPS-039 Use health checks carefully to avoid restart loops or cascading failures during dependency outages or high load.
• OPS-043 Ensure backup, restore, and recovery prerequisites are identified and handed to the reliability review owner.

Deployment and rollback#

• OPS-044 Define the deployment sequence, prerequisites, affected systems, and responsible operator for each production release.
• OPS-045 Make application deployment steps automated and repeatable, with documented manual interventions only where justified.
• OPS-046 Identify the exact immutable artifact, configuration revision, migration version, and source commit being deployed.
• OPS-048 Use progressive rollout, rolling update, blue/green deployment, canary, or feature flags when the risk warrants gradual exposure.
• OPS-050 Run appropriate smoke checks against the deployed artifact in the target environment before broad promotion.
• OPS-051 Require critical pre-deployment quality/security checks and dependency compatibility checks before production traffic changes.
• OPS-052 Document whether database and schema changes support both old and new application versions during rollout.
• OPS-057 Ensure a failed deployment stops further promotion and reports the failure to the release owner.
• OPS-060 Confirm secrets and credentials are not exposed by deployment logs, shell traces, generated manifests, or failed jobs.
• OPS-062 Define post-deployment verification for critical transactions, business workflows, and dependent integrations.
• OPS-063 Record the outcome of each deployment, including version, operator or automation, changes, and rollback status.
• OPS-049 Define expected startup, readiness, warm-up, and connection-draining behavior before routing traffic to a new version.

Delivery governance#

• OPS-064 Define who can change CI configuration, approve production promotions, and access deployment credentials.
• OPS-066 Require review and traceable approval for consequential workflow, environment, or deployment-policy changes.
• OPS-067 Record change history linking request or issue, reviewed source revision, build artifact, approval, and deployed version.
• OPS-071 Assign owners and review schedules for runner images, build dependencies, deployment infrastructure, and automation maintenance.
• OPS-072 Define and measure delivery performance indicators such as deployment frequency, change lead time, change failure, and recovery time with consistent definitions.
• OPS-074 Assess reliability and cost of CI runners, artifact storage, and test infrastructure against project needs.
• OPS-075 Document incident investigation and follow-up for recurring build, infrastructure, or deployment failures.
• OPS-078 Review operational documentation and ownership after adopting new release tools or changing infrastructure architecture.
• OPS-079 Retire unused deployment jobs, stale credentials, obsolete environments, and unsupported build workflows.

API Checks#

• OPS-081 Build and deploy API services with reproducible artifacts and known version identifiers.
• OPS-082 Validate deployed API schemas against their approved OpenAPI or equivalent contract where one exists.
• OPS-083 Run consumer/provider contract tests in CI for public or cross-team API changes according to compatibility risk.
• OPS-084 Detect breaking changes to fields, validation, authentication requirements, errors, and versioned endpoints before promotion.
• OPS-085 Verify deployment ordering and compatibility when API providers and consumers release independently.
• OPS-086 Run smoke checks for authentication, authorization boundaries, and critical API workflows in the target environment.
• OPS-087 Include health and readiness endpoints that represent the service's ability to receive traffic without exposing sensitive internals.
• OPS-088 Set and verify ingress, gateway, service-discovery, and routing configurations for each API environment.
• OPS-089 Ensure API and worker rollouts respect in-flight requests, message consumption, and graceful shutdown behavior.
• OPS-090 Define and test retry/idempotency expectations before shifting traffic between API versions.
• OPS-091 Document API version changes, deprecation periods, and consumer notification responsibilities in release procedures.
• OPS-092 Validate database migration compatibility with both prior and new API versions throughout the rollout.
• OPS-093 Configure API rate limits, upstream timeouts, and quotas consistently across deployment environments where applicable.
• OPS-094 Monitor critical endpoint latency, error rates, and traffic during canaries or post-release observation.
• OPS-095 Verify third-party integration credentials, webhook routing, callback addresses, and network permissions in the target environment.
• OPS-096 Confirm API logs, traces, and health diagnostics are safe for production and do not capture sensitive request payloads unnecessarily.
• OPS-097 Exercise API rollback or forward recovery without leaving consumers on an unsupported contract.

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 API and service behavior 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 backend / API 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.