15 — 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: Frontend-specific. This file is one part of the 15_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.

Frontend Checks#

• OPS-098 Produce versioned frontend artifacts with reproducible asset manifests and predictable configuration injection.
• OPS-099 Verify the selected static, server-rendered, or hybrid deployment mode works in all supported target environments.
• OPS-100 Test that entry points, deep links, and client-side routes resolve correctly after deployment and browser refresh.
• OPS-101 Validate environment-specific public API base URLs, feature flags, and non-secret frontend configuration before promotion.
• OPS-102 Ensure secrets or server-side signing credentials are never included in client bundles, static assets, or public source maps.
• OPS-103 Validate asset fingerprinting, CDN cache headers, and invalidation so users do not receive incompatible versions of code and data.
• OPS-104 Keep HTML caching compatible with the active JavaScript/CSS asset version and deployment strategy.
• OPS-105 Coordinate frontend and API deployment compatibility so temporarily mixed versions still support critical workflows.
• OPS-106 Check that new and old clients can handle planned API changes during progressive deployments.
• OPS-107 Run post-deployment smoke checks for login, navigation, primary forms, and critical browser interactions.
• OPS-108 Verify correct handling of staging versus production indexing, canonical tags, and robots directives for public sites.
• OPS-109 Include targeted accessibility, visual regression, and browser compatibility checks in relevant delivery stages.
• OPS-110 Validate service-worker updates, offline caches, and installed-app refresh paths where the product uses them.
• OPS-111 Check that feature flags can disable risky frontend behavior without making the existing experience unusable.
• OPS-112 Measure key page loading, runtime errors, and user interaction health during staged rollouts.
• OPS-113 Ensure deployment and rollback do not leave users with broken in-progress forms, expired state, or inaccessible resources.
• OPS-114 Verify frontend release errors and telemetry are correlated to the deployed version without logging personal data or credentials.

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 browser and client 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 frontend 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.