A deployment that requires a developer to manually run steps and watch for errors is a deployment that will eventually go wrong at the worst possible moment.

Pipeline triggered on every pull request with a test-build-scan sequence that blocks merge on failure. Test stage: Jest or Vitest for JavaScript/TypeScript unit and integration tests; pytest for Python; Playwright for end-to-end tests run against a temporary environment spun up for the PR. ESLint and TypeScript tsc --noEmit for static analysis -- type errors that pass locally but fail on the CI node catch configuration drift between developer machines. Dependency security scanning via GitHub Dependabot or Snyk (CVE severity threshold configurable -- high and critical block merge, low and medium warn). Build stage: Docker image built with BuildKit cache mounts for package manager cache so a 3-minute npm install drops to 20 seconds on a cached build. Multi-stage Dockerfile producing a minimal production image -- a 1.2GB development image becoming a 180MB production image. Image pushed to Amazon ECR, Google Artifact Registry, or GitHub Container Registry with the commit SHA as the image tag. The artifact that passed tests is the exact artifact that gets promoted through environments -- no rebuilding at deploy time.

Automated deployment to staging triggered on merge to the main branch -- using the exact Docker image that passed the CI test suite rather than rebuilding, so the artifact provenance is unbroken from test to deploy. Blue-green deployment to staging: the new version starts alongside the old one, health checks pass, then traffic switches atomically -- staging is never in a broken intermediate state where half the requests hit the old version and half hit the new. ECS, Kubernetes, or Railway deployment via task definition update or Helm chart rollout depending on your infrastructure. Environment variable injection at deploy time from secrets manager -- staging injects staging credentials, never production credentials, enforced by the pipeline rather than by convention. Smoke tests after deployment: HTTP health check against the /health endpoint, a smoke test suite that hits the 5 most critical API paths, and a database connectivity check. Slack or Teams notification with the deployed commit SHA, the deploying actor, and a direct link to the pipeline run -- so the team knows without checking the dashboard.

Promotion from staging to production through a controlled, auditable process -- not a one-click button anyone can press. GitHub Environments with required reviewers: the pipeline pauses at the production deployment step and waits for approval from a named reviewer or team before proceeding. Deployment window enforcement configured as a pipeline condition: a time-of-day check prevents production deployments outside approved windows (no Friday 4pm deploys, no deployments during peak business hours for customer-facing services). The staging-to-production promotion uses the exact same image tag that ran in staging -- the promotion step is a tag reference change, not a new build. Deployment record in the pipeline audit log captures the approving user, the approval timestamp, the version deployed, the deploying actor, and the pre- and post-deployment commit SHAs. Datadog or Grafana deployment annotation created automatically at deploy time so the monitoring team can see deployment events on metric graphs when investigating a production incident. Full audit trail available for compliance requirements (SOC 2 change management evidence, FCA/PCI change control) without requiring a separate ITSM tool.

Every deployment tagged with the exact commit SHA and image tag so there is never ambiguity about what is running in production -- and rollback is a precise operation, not a guess about which version to go back to. One-click rollback from the pipeline dashboard: the rollback job redeploys the previous image tag without requiring a code revert and a new build cycle. Target rollback time under 5 minutes from decision to traffic serving the previous version. Automated rollback trigger for post-deployment health check failures: the pipeline monitors error rate, HTTP 5xx percentage, and health check response for 5 minutes after deployment; if a configured threshold is breached (e.g., error rate above 5%), the rollback job runs automatically without requiring a human to notice and trigger it. Canary deployment option for higher-risk releases: route 5% of production traffic to the new version, monitor for 10 minutes, then either promote to 100% or rollback. Deployment history retained for 90 days with the commit SHA, artifact version, deploying actor, and deployment duration -- available for incident investigation and SOC 2 change management evidence without requiring a separate ITSM tool.

Pipeline duration directly affects how developers work: a pipeline that takes 45 minutes creates pressure to batch changes into larger commits, skip tests locally, and work around the feedback loop. Target under 15 minutes for a complete test-build-deploy-to-staging cycle. Dependency caching strategy: GitHub Actions cache with a composite key based on package-lock.json hash -- cache hits avoid re-downloading the full dependency tree; a 3-minute npm install drops to 15 seconds on a warm cache. Docker BuildKit layer caching: base image layers and package installation layers cached separately from application code layers so a code-only change doesn't rebuild the package installation layer. Parallel job execution: unit tests, integration tests, and linting run as separate jobs in parallel rather than sequentially. Turborepo or Nx for monorepos: affected-package detection runs only the tests, builds, and checks for packages changed by the pull request -- in a 15-package monorepo, a change to one package runs 1/15th of the total test suite rather than all of it. Test sharding for large test suites: Jest --shard or pytest-split distributes the test suite across multiple parallel runners, reducing a 20-minute single-runner suite to a 4-minute 5-runner suite.

Secrets stored in a dedicated secrets manager rather than hardcoded in pipeline YAML files, .env files committed to version control, or passed as unencrypted environment variables through pipeline variables. GitHub Secrets for simple single-repository setups: secrets encrypted at rest, never visible in logs, and accessible only to authorised jobs. AWS Secrets Manager or GCP Secret Manager for teams that need centralised secret management across multiple services and pipelines -- injected at deploy time via IAM role rather than long-lived credentials. OIDC-based authentication between the pipeline and cloud provider: the pipeline authenticates as a short-lived federated identity with scoped permissions rather than using a stored AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY that never expire and have broad access. HashiCorp Vault for enterprises with compliance requirements around secret rotation and access auditing -- dynamic secrets that expire after a configurable TTL, eliminating long-lived database credentials entirely. Secret rotation procedures documented and automated where rotation can be triggered from the pipeline: database password rotation in Secrets Manager triggers an ECS task to restart with the new credentials within a configurable window. Audit log of every secret access with the job ID, timestamp, and requesting identity.