DevOps Tutorials, Guides & Best Practices

A CI/CD pipeline supports rapid deployment when every change follows the same short, observable path: verify the commit, build one immutable artifact, promote that exact artifact, prove the rollout is healthy, and keep a tested rollback reference. Speed comes from small changes and fast evidence, not from removing release controls.

Short recommendation: build once, identify the artifact by digest, promote it through environments without rebuilding, and make every deployment produce a release record. A pipeline that cannot answer *what changed, what was tested, what was deployed, whether it is healthy, and how to roll it back* is not ready for frequent production releases.

The rapid-deployment pipeline contract

Treat the pipeline as a chain of evidence-producing decisions. Each stage accepts a known input, runs bounded checks, and emits proof for the next stage.

This model separates continuous delivery from continuous deployment. Continuous delivery keeps a verified release ready for production. Continuous deployment automatically promotes every change that satisfies the defined policy. The pipeline structure can support either model; the production approval policy decides which one you use.

Build once, then promote by digest

Rebuilding for staging and production creates two artifacts from one commit. Dependency mirrors, timestamps, base-image movement, and build environment differences can make those artifacts diverge even when the source SHA is unchanged.

Build once and record both identifiers:

– the commit SHA identifies the source revision;

– the artifact digest identifies the exact bytes promoted to each environment.

A GitHub Actions build job can expose the image digest to downstream jobs. This example uses current major action versions, a pinned Node runtime, npm ci, and GitHub Container Registry authentication through the workflow token rather than a long-lived registry password.

name: Build release artifact

on:
  push:
    branches: [main]

permissions:
  contents: read
  packages: write
  id-token: write
  attestations: write

env:
  IMAGE: ghcr.io/acme/api

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      image_digest: ${{ steps.image.outputs.digest }}
    steps:
      - uses: actions/checkout@v7

      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm

      - run: npm ci
      - run: npm test

      - uses: docker/login-action@v4
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - id: image
        uses: docker/build-push-action@v7
        with:
          context: .
          push: true
          tags: ${{ env.IMAGE }}:${{ github.sha }}

      - uses: actions/attest-build-provenance@v4
        with:
          subject-name: ${{ env.IMAGE }}
          subject-digest: ${{ steps.image.outputs.digest }}
          push-to-registry: trueCode language: YAML (yaml)

The exact action majors will change over time. Dependabot or Renovate can propose updates, but the pipeline should review and test those updates like other code. When you choose a runner or orchestrator, Jenkins vs TeamCity compares two common paths.

Put the fastest feedback first

A rapid pipeline fails cheap tests before it reserves scarce environments or waits on broad integration suites.

Do not make one giant job that hides which gate failed. Separate jobs can run independent checks in parallel, while downstream deployment jobs depend only on the evidence they require.

Use manual approval where consequence demands it, not as a substitute for missing tests. Production credentials should be environment-scoped, short-lived where supported, and unavailable to pull-request jobs. GitHub environments can add protection rules and restrict deployment secrets; other CI systems provide equivalent protected environments. For deeper test-method guidance, see DevOps testing best practices.

Design deployment health into the workload

The pipeline can only verify what the application exposes. For Kubernetes, a readiness probe controls whether a Pod receives Service traffic. A liveness probe asks whether the container should be restarted. A startup probe protects slow-starting containers from premature liveness failures.

The deployment strategy and probes should support an observable rollout:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 4
  minReadySeconds: 10
  progressDeadlineSeconds: 300
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          # Example only: the pipeline replaces this zero digest with build output.
          image: ghcr.io/acme/api@sha256:0000000000000000000000000000000000000000000000000000000000000000
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            periodSeconds: 5
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            periodSeconds: 10
            failureThreshold: 3Code language: YAML (yaml)

maxUnavailable: 0 is not free availability. It requires enough cluster capacity for the surge Pod, and it does not prove the new application version is correct. The readiness endpoint must check only dependencies required to serve traffic; an overly broad or unstable check can remove healthy capacity.

Use an ordered promotion and rollback workflow

The safest rapid path is repetitive. Automate the same steps for every release and store their outputs.

1. Capture the release identity

Start with the commit SHA, immutable image digest, workflow run, actor, target environment, and rollback digest. Do not rely on a mutable latest tag as the production identity.

2. Promote the existing artifact to staging

Apply environment-specific configuration without rebuilding the image. Keep secrets outside the image and retrieve them through the target platform’s secret mechanism.

3. Wait for platform rollout evidence

For a direct Kubernetes deployment path, set the image by digest and wait for the Deployment controller:

set -euo pipefail

NAMESPACE=staging
DEPLOYMENT=api
CONTAINER=api
IMAGE="ghcr.io/acme/api@${IMAGE_DIGEST}"

kubectl -n "$NAMESPACE" set image \
  "deployment/$DEPLOYMENT" "$CONTAINER=$IMAGE"

kubectl -n "$NAMESPACE" rollout status \
  "deployment/$DEPLOYMENT" --timeout=5m

curl --fail --silent --show-error \
  "https://staging.example.com/ready"Code language: Bash (bash)

If GitOps owns the workload, do not have the CI job and GitOps controller mutate the same Deployment independently. Update the versioned desired state, let the reconciler apply it, and record the reconciled revision and health result. OpenGitOps defines desired state as declarative, versioned and immutable, automatically pulled, and continuously reconciled.

4. Run staging checks against the deployed artifact

Verify the running image digest, required migrations, API contracts, critical user flow, and logs. A successful kubectl rollout status proves controller progress, not end-to-end business behavior.

5. Promote the same digest to production

Use a rolling, canary, or blue-green strategy that matches the platform and risk. Define stop conditions before deployment, for example:

– rollout exceeds five minutes;

– readiness never reaches the expected replica count;

– smoke test fails;

– error rate or latency exceeds the service’s release threshold;

– a critical business transaction fails.

6. Observe before declaring success

Keep the deployment open through a bounded observation window. Link metrics, logs, traces, alerts, and the workflow run to the release identity. The dedicated DevOps monitoring guide covers the observability layer; the pipeline should consume those signals rather than invent a separate monitoring system.

7. Roll back by known artifact reference

For a direct Kubernetes rollout, first inspect history and status:

kubectl -n production rollout history deployment/api
kubectl -n production rollout status deployment/api --timeout=5m

# Use only after the stop condition has been met and the target is confirmed.
kubectl -n production rollout undo deployment/api
kubectl -n production rollout status deployment/api --timeout=5mCode language: Bash (bash)

A rollback does not automatically reverse a destructive database migration. Use backward-compatible schema changes, separate expand and contract steps, and test the application rollback while the newer schema is present.

Make release evidence a first-class artifact

A deployment notification is not a release record. Store a machine-readable record that ties the decision chain together.

{
  "service": "api",
  "environment": "production",
  "commit_sha": "8f31c9d",
  "artifact": "ghcr.io/acme/api@sha256:...",
  "test_run": "ci/18422",
  "provenance": "attestation/sha256:...",
  "deployed_at": "2026-09-01T08:15:00Z",
  "rollout": "passed",
  "smoke_test": "passed",
  "rollback_artifact": "ghcr.io/acme/api@sha256:previous..."
}Code language: JSON / JSON with Comments (json)

The values must come from the real workflow. Do not copy this sample timestamp or these example digests into production automation.

Artifact attestations can establish where and how an artifact was built. They do not prove that the source is safe, the tests are sufficient, or the production rollout is healthy. Treat provenance, test evidence, and runtime verification as separate controls.

Measure flow and instability together

DORA’s current software delivery performance model uses five metrics. Measure them for one application or service over time rather than turning them into a competition between unlike teams.

Do not optimize deployment frequency in isolation. A faster pipeline that increases failed changes, recovery time, or emergency rework is moving work downstream rather than improving delivery. When the team is ready to improve beyond a single pipeline, the DevOps maturity model frames the next level of shared ownership.

For a platform-specific optimization pass, use Azure CI/CD Pipeline Optimization. For security-tool selection, keep this architecture guide focused and use DevOps Security Tools for CI/CD as the adjacent tool-oriented page.

Common pipeline designs that slow releases

– Rebuilding per environment: staging and production may receive different bytes. Promote one digest instead.

– Mutable deployment tags: latest hides the exact release and weakens rollback. Record an immutable digest.

– A single long test job: failures arrive late and ownership is unclear. Run independent fast checks in parallel and reserve broad tests for the verified artifact.

– Production-only migrations: deployment becomes the first compatibility test. Rehearse migrations and use backward-compatible expand/contract steps.

– Green pipeline, unknown service: job success is not user success. Add readiness, smoke, service-level, and business checks.

– Automatic rollback without a defined signal: noise can trigger more change during an incident. Define stop conditions, rollback authority, and the exact rollback reference.

– CI and GitOps both writing the same object: two controllers can fight. Choose one owner for desired state.

– Shared long-lived production credentials: one compromised job can cross environment boundaries. Use protected environments and short-lived identity where the platform supports it.

Sources

DORA software delivery performance metrics

GitHub Actions deployment documentation

GitHub artifact attestations

Kubernetes Deployments

Kubernetes liveness, readiness, and startup probes

OpenGitOps principles

FAQ