CI/CD: از build تا استقرارِ امنCI/CD: From Build to Safe Deployment

One senior-interview question floors a lot of people: "From git push to a real user seeing your code, what exactly does it pass through?" The junior answer is "Jenkins builds it and deploys it." The senior answer is a chain: what gets built, how many times, who signs it, when the database migrates, how you get back if it breaks, and how you find out it broke.

This chapter is that chain — not a tour of tools, but the engineering of the delivery path. Anything covered elsewhere is only referenced: tests in testing, Maven/Gradle in build-tools, Docker and Kubernetes in containers-jvm, metrics and logs in observability, keys in key-management-secrets.

1. The problem CI solves

CI: continuous integration

Continuous Integration means every developer merges into the mainline at least once a day, and every merge is built and tested automatically. Two words in that definition get ignored:

• "into the mainline": if you work three weeks on a feature branch and the pipeline is green on that branch, you don't have CI — you have a build server. CI means your code is actually combined with everyone else's.
• "automatically": if someone has to press a button or run a script on their laptop, sooner or later it won't run.

Three questions tell you whether you really have CI: do branches live less than a day? When the pipeline goes red, is turning it green the top priority? Is main always releasable? If not, you have CI theatre. This is why CI fights long-lived branches: GitFlow was built for quarterly releases, while a service deploying several times a day wants trunk-based development — short-lived branches, daily merges, feature flags for unfinished work.

CD: continuous delivery vs continuous deployment

This is exactly where interviewers stop.

• Continuous Delivery: anything out of a green pipeline is ready for production — built, tested, signed. A human presses the button; shipping is a commercial decision, not a technical one.
• Continuous Deployment: the same minus the button — every commit that clears the gates goes to production automatically.

The difference is one button, and it can only be removed when tests, feature flags, canaries and automated rollback are mature enough that no human is needed.

2. Anatomy of a Java service pipeline

«مراحل خط لولهٔ یک سرویس Java و ترتیب منطقی‌شان» — Stages of a Java service pipeline and their ordering logic

flowchart TD
  A[1. Checkout] --> B[2. Restore dependency cache]
  B --> C[3. Compile]
  C --> D[4. Unit tests]
  D --> E[5. Integration tests / Testcontainers]
  D --> F[6. Static analysis + quality gate]
  E --> G[7. Dependency + container scan]
  F --> G
  G --> H[8. Package artifact + build image]
  H --> I[9. Push image + sign]
  I --> J[10. Deploy per environment]
  J --> K[11. Smoke tests + observe]

One principle drives that order: fail fast. Cheapest and fastest checks first; if the code doesn't compile, five minutes of security scanning is pointless.

2.1 Checkout

A shallow clone (git clone --depth 1) saves tens of seconds on a big repo but breaks anything needing history — git describe, changelogs, or Sonar deciding what "new code" is; in GitHub Actions use fetch-depth: 0. The bigger issue is workspace cleanliness: an agent up for months has a shared ~/.m2 and orphaned Testcontainers containers, so today's build goes green on something tomorrow's won't have. The standard answer is an ephemeral runner in a container.

2.2 Dependency cache

Without a cache, every job re-downloads the whole Maven dependency tree — two to three wasted minutes each.

mvn -B -ntp dependency:go-offline                      # warm the local repository
mvn -B -ntp -Dmaven.repo.local=.m2/repository verify   # local repo inside the project so the runner can cache it

2.3 Compile and unit tests

mvn -B -ntp -T 1C clean verify -DskipITs

None of those flags are decoration: -B is batch mode (no colour, no prompts), -ntp drops the download progress bar, -T 1C runs one thread per CPU core, -DskipITs skips only integration tests, and --fail-at-end keeps a multi-module build going so you see all errors at once.

The split everybody gets wrong: Surefire runs unit tests in the test phase (*Test, Test*), Failsafe runs integration tests in integration-test and checks results in verify (*IT). If Failsafe fails, post-integration-test still runs so resources get released.

2.4 Integration tests with Testcontainers

Writing tests belongs to testing; here only the CI part: Testcontainers needs a reachable Docker daemon. Three models: mounting the host Docker socket (fastest, but the job effectively gets root there), Docker-in-Docker as a service (isolated, slower), or a remote Docker endpoint.

integration-test:
  stage: test
  image: maven:3.9-eclipse-temurin-21
  services:
    - name: docker:27-dind
      alias: docker
  variables:
    DOCKER_HOST: "tcp://docker:2376"
    DOCKER_TLS_CERTDIR: "/certs"
    DOCKER_CERT_PATH: "/certs/client"
    DOCKER_TLS_VERIFY: "1"
  script:
    - mvn -B -ntp -Dmaven.repo.local=.m2/repository verify

2.5 Static analysis and quality gates

Static analysis means inspecting code without running it. Three layers that get conflated: formatting (Spotless, Checkstyle — subjective, auto-fix it), bug detection (SpotBugs on bytecode, plus Find Security Bugs for security patterns), and accumulated quality (SonarQube, focused on "new code").

mvn -B -ntp com.github.spotbugs:spotbugs-maven-plugin:check    # bug detection on bytecode

mvn -B -ntp verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar \
    -Dsonar.projectKey=payments-service \
    -Dsonar.host.url="$SONAR_HOST_URL" \
    -Dsonar.token="$SONAR_TOKEN" \
    -Dsonar.qualitygate.wait=true

sonar.qualitygate.wait=true is critical: without it Maven ships the analysis and returns success immediately, so the gate can never break the build. And for Sonar to see coverage the JaCoCo agent must attach before the tests run (jacoco-maven-plugin with prepare-agent and report).

The senior nuance: static analysis costs something too — false positives. If 40% of findings are wrong, the team learns to ignore all of them. Start with few precise rules, suppress with a comment, tighten gradually; a noisy gate is worse than no gate.

2.6 Dependency and container scanning

There are two different kinds of scan. SCA (Software Composition Analysis) matches your third-party libraries against vulnerability databases:

mvn -B -ntp org.owasp:dependency-check-maven:12.2.2:check \
    -DfailBuildOnCVSS=7 -DnvdApiKey="$NVD_API_KEY"

Image scanning inspects the OS layers of the image you built:

IMAGE=registry.example.com/team/payments:1.4.2
trivy image --exit-code 1 --severity HIGH,CRITICAL --ignore-unfixed "$IMAGE"
trivy image --format cyclonedx --output sbom.cdx.json "$IMAGE"

An SBOM (Software Bill of Materials) lists exactly which libraries and versions are inside an artifact; the dominant formats are CycloneDX and SPDX. Its value shows the day a big vulnerability drops and a manager asks "which of our services ship that library?" — with an SBOM that's one query, without it a week of manual work.

2.7 Building the artifact and image

The most important rule here: build once, promote many. Build the artifact once and move those same bytes from dev to staging to production. Rebuild per environment and what you tested in staging is not what runs in production — "but it worked in staging" becomes the standing post-mortem line.

2.8 Signing and provenance

Scanning answers "is there something bad inside this image?"; signing answers "did this image really come from our pipeline?" In supply-chain attacks the second matters more. Sigstore/cosign makes keyless signing possible: the pipeline gets an OIDC token from the CI provider, Fulcio issues a short-lived certificate, and the signature lands in the Rekor transparency log — no private key to steal.

cosign sign --yes registry.example.com/team/payments@sha256:9f8c...

cosign verify \
  --certificate-identity "https://github.com/team/service/.github/workflows/build.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  registry.example.com/team/payments@sha256:9f8c...

Signing is easy; the value appears when something rejects an unsigned image — in Kubernetes, a policy admission controller. Without that, a signature is decoration.

2.9 Deploy and smoke tests

A smoke test is a few small, fast checks right after deployment saying "the service is up and doing its job" — not a full suite, just no smoke.

kubectl rollout status deployment/payments --namespace prod --timeout=180s

# confirm the deployed version is the one we expected
curl --fail --silent https://payments.example.com/actuator/info | jq -e '.build.version == "1.4.2"'

3. The same pipeline in three tools

A Spring Boot service on Maven, Java 21.

3.1 GitLab CI

stages: [build, test, package, deploy]

default:
  image: maven:3.9-eclipse-temurin-21
  interruptible: true          # cancel an old run when a new push arrives
  cache:
    key:
      files: [pom.xml]         # key derived from pom contents
    paths: [.m2/repository]
    policy: pull               # only the build job writes the cache

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository"
  MAVEN_CLI_OPTS: "-B -ntp --fail-at-end"

compile:
  stage: build
  cache:
    key: { files: [pom.xml] }
    paths: [.m2/repository]
    policy: pull-push          # this is the job that fills the cache
  script:
    - mvn $MAVEN_CLI_OPTS -DskipTests clean package
  artifacts:
    paths: [target/*.jar]
    expire_in: 1 day

test:
  stage: test
  needs: [compile]
  script:
    - mvn $MAVEN_CLI_OPTS verify sonar:sonar -Dsonar.qualitygate.wait=true
  artifacts:
    when: always
    reports:
      junit: target/*-reports/TEST-*.xml

package-image:
  stage: package
  image: docker:27
  services: [docker:27-dind]
  needs: [compile]
  variables:
    IMAGE: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
  script:
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
    - docker build -t "$IMAGE" .
    - docker push "$IMAGE"
    - trivy image --exit-code 1 --severity HIGH,CRITICAL --ignore-unfixed "$IMAGE"

deploy-staging:
  stage: deploy
  needs: [package-image]
  environment:
    name: staging
    url: https://staging.example.com
    deployment_tier: staging
  id_tokens:
    VAULT_ID_TOKEN:                    # OIDC token used to fetch secrets from Vault
      aud: https://vault.example.com
  script:
    - ./deploy.sh staging "$CI_COMMIT_SHORT_SHA"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy-prod:
  stage: deploy
  needs: [deploy-staging]
  environment:
    name: production
    deployment_tier: production
  when: manual                         # the human gate: continuous delivery
  script:
    - ./deploy.sh production "$CI_COMMIT_SHORT_SHA"
  rules:
    - if: $CI_COMMIT_TAG

needs is the most important keyword for speed: without it no job in the next stage starts until every job of the previous one finishes; with it you get a DAG where each job starts as soon as its own prerequisite is done — typically 30–50% off wall-clock time. interruptible: true cancels superseded runs and keeps the runner queue free.

3.2 GitHub Actions

name: build-and-deploy

on:
  push:
    branches: [main]
    tags: ['v*']
  pull_request:

permissions:
  contents: read               # minimal default; each job adds what it needs

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0       # Sonar and versioning tools need history

      - uses: actions/setup-java@v5
        with:
          distribution: temurin
          java-version: '21'
          cache: maven         # built-in ~/.m2 cache keyed on the pom hash

      - run: mvn -B -ntp --fail-at-end verify

  image:
    needs: build
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write          # required for keyless signing with cosign
    steps:
      - uses: actions/checkout@v5
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - id: push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

      - run: cosign sign --yes ghcr.io/${{ github.repository }}@${{ steps.push.outputs.digest }}

  deploy-prod:
    needs: image
    if: startsWith(github.ref, 'refs/tags/v')
    runs-on: ubuntu-latest
    environment: production     # approval rules live in the environment settings
    steps:
      - run: ./deploy.sh production "${{ github.sha }}"

- uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0

3.3 Jenkins — declarative pipeline

pipeline {
  agent {
    docker {
      image 'maven:3.9-eclipse-temurin-21'
      args '-v $HOME/.m2:/root/.m2'
    }
  }

  options {
    timeout(time: 30, unit: 'MINUTES')
    buildDiscarder(logRotator(numToKeepStr: '30'))
    disableConcurrentBuilds()
  }

  environment { IMAGE = "registry.example.com/team/payments"; TAG = "${env.GIT_COMMIT.take(8)}" }

  stages {
    stage('Build') {
      steps { sh 'mvn -B -ntp -DskipTests clean package' }
    }

    stage('Test') {
      steps { sh 'mvn -B -ntp verify' }
      post  { always { junit 'target/*-reports/TEST-*.xml' } }
    }

    stage('Image') {
      steps {
        withCredentials([usernamePassword(credentialsId: 'registry',
                                          usernameVariable: 'REG_USER',
                                          passwordVariable: 'REG_PASS')]) {
          sh '''
            echo "$REG_PASS" | docker login -u "$REG_USER" --password-stdin registry.example.com
            docker build -t "$IMAGE:$TAG" .
            docker push "$IMAGE:$TAG"
          '''
        }
      }
    }

    stage('Deploy to production') {
      when { buildingTag() }
      input {
        message "Deploy ${TAG} to production?"
        submitter "release-managers"
      }
      steps { sh './deploy.sh production "$TAG"' }
    }
  }

  post { cleanup { cleanWs() } }
}

The three tools compared

4. Build reproducibility and the artifact repository

A reproducible build means the same source, command and environment produce a byte-for-byte identical output; without it you cannot prove which commit the production artifact came from. The obstacle in Java: a jar is a zip, and zip stores a timestamp per entry, so every build yields a different hash even if no code changed. Maven's answer is a property:

<properties>
  <project.build.outputTimestamp>2026-07-01T00:00:00Z</project.build.outputTimestamp>
</properties>

mvn artifact:check-buildplan shows which plugins are still incompatible; from the 4.x line Maven enables this by default. But reproducibility needs the non-deterministic inputs gone too: SNAPSHOT dependencies, base images on floating tags, downloads straight from the internet mid-build. The cure for all three: fixed versions, fixed digests, everything through an internal mirror.

Nexus and Artifactory

An artifact repository plays three roles: proxy (a mirror of public repositories, so your build survives an internet outage or a deleted upstream package), hosted (where your own artifacts are published), and group (one URL fronting several repositories). In ~/.m2/settings.xml on the runner you define a <mirror> with <mirrorOf>*</mirrorOf> so all downloads come from inside, and put publishing credentials in <servers>, reading their values from environment variables.

Maven-in-CI cheat sheet

1.4.2-SNAPSHOT means "the contents may change on every fetch"; if a release-path artifact depends on one, yesterday's and today's builds are different things. Enforce it with maven-enforcer's requireReleaseDeps rule, and set repository retention: SNAPSHOTs purged after 30 days, releases never overwritten.

5. Versioning and automated release

Semantic Versioning (SemVer) is MAJOR.MINOR.PATCH: MAJOR for a backward-incompatible change, MINOR for a compatible capability, PATCH for a compatible fix. For a library the contract is vital because consumers decide on it; for a deployed service it matters less, and many teams use date-based versions or the commit hash. What matters is that it is unique, ordered and traceable to one commit.

Conventional Commits is a small contract on the commit message that a machine can read:

feat(payments): add idempotency key to transfer API
fix(auth): reject expired refresh tokens
feat(api)!: remove deprecated /v1/transfer endpoint

fix means PATCH, feat means MINOR, and ! or BREAKING CHANGE means MAJOR. With that convention, tooling can compute the next version and the changelog for you.

Many teams dropped maven-release-plugin because release:prepare release:perform builds twice, pushes two commits, and fights detached HEADs and scoped tokens in CI. The modern pattern: derive the version from the tag, build once, publish that artifact, generate the changelog from conventional commits (JReleaser or semantic-release automate this). The invariant: a version is a label on an artifact, not a reason to rebuild.

6. Environment promotion and config

Promotion means moving the same artifact into an environment that demands more trust: build once, then dev (automatic) → test (automatic + e2e) → staging (production-like) → gate → production (canary first, then full). The key point: configuration lives outside the artifact and is injected at runtime.

Three layers stack up: safe defaults in the artifact (server.port=8080), per-environment values from env vars (spring.datasource.url=${DB_URL}), and secrets from a Secret or Vault (spring.datasource.password=${DB_PASSWORD}) — never a file inside the image.

Two rules help. First, fail fast on configuration: if a required variable is missing the service must die at startup, not come up on a default and behave strangely hours later (in Spring, @ConfigurationProperties plus @Validated). Second, keep per-environment differences few; the more staging and production differ, the less a staging test is worth.

One warning: spring.profiles.active=prod picking a URL is harmless, but when a profile decides which @Bean gets created you are running a different application in staging, and a bug that only appears with the real bean shows up first in production. A profile should change values, not the object graph.

7. Secrets in CI, done safely

Historically, to let a pipeline deploy to a cloud you put a long-lived key in CI variables that stayed alive for years. With OIDC the CI provider signs a short-lived token per job with claims like "repo X, branch main, this workflow"; the other side verifies it and returns a credential valid for minutes. No long-lived secret is left to steal.

# GitLab: request an ID token for Vault
deploy-prod:
  id_tokens:
    VAULT_ID_TOKEN:
      aud: https://vault.example.com
  secrets:
    DB_PASSWORD:
      vault: prod/payments/db@ops

8. Database migrations in the pipeline

flyway -url="$DB_URL" -user="$DB_USER" -password="$DB_PASSWORD" migrate

liquibase --changelog-file=db/changelog-master.yaml rollback --tag=v1.4.1

The expand-contract pattern

«چهار گام تغییر سازگارِ عقب‌رو در schema» — Four phases of a backward-compatible schema change

stateDiagram-v2
  [*] --> Expand: add new column, keep old
  Expand --> DualWrite: app writes both, reads old
  DualWrite --> Migrate: backfill + switch reads
  Migrate --> Contract: drop old column
  Contract --> [*]

Each phase is its own release, and the golden rule is: every version of the application must work with the schema before and after it. Example: renaming email to email_address with no downtime.

Phase 1 — expand: add the new column, nullable and unconstrained.

ALTER TABLE customers ADD COLUMN email_address varchar(320);

ALTER TABLE customers ADD (email_address VARCHAR2(320));

Phase 2 — dual write: the new version writes both columns and still reads the old one.

Phase 3 — backfill: move the old data in batches, never in one giant UPDATE.

UPDATE customers SET email_address = email
 WHERE email_address IS NULL
   AND id IN (SELECT id FROM customers WHERE email_address IS NULL
              ORDER BY id LIMIT 10000);

UPDATE customers SET email_address = email
 WHERE email_address IS NULL
   AND id IN (SELECT id FROM customers WHERE email_address IS NULL
              ORDER BY id FETCH FIRST 10000 ROWS ONLY);

Then build the index without locking the table and tighten the constraint under a lock timeout:

CREATE INDEX CONCURRENTLY idx_customers_email_address ON customers (email_address);
SET lock_timeout = '3s';
ALTER TABLE customers ALTER COLUMN email_address SET NOT NULL;

CREATE INDEX idx_customers_email_address ON customers (email_address) ONLINE;
ALTER SESSION SET ddl_lock_timeout = 3;
ALTER TABLE customers MODIFY (email_address NOT NULL);

Phase 4 — contract: once you are sure no old version is running, drop the old column.

ALTER TABLE customers DROP COLUMN email;

ALTER TABLE customers SET UNUSED (email);
ALTER TABLE customers DROP UNUSED COLUMNS;

In Oracle, SET UNUSED is instant while DROP UNUSED COLUMNS does the heavy work in a quiet window; in PostgreSQL DROP COLUMN only hides the column but still takes a brief exclusive lock.

9. Deployment strategies

«چهار الگوی استقرار و نحوهٔ جابه‌جایی ترافیک» — Four deployment patterns and how traffic moves

flowchart TD
  subgraph Recreate
    R1[Stop v1] --> R2[Start v2]
  end
  subgraph Rolling
    O1[v1 pods] --> O2[replace one by one] --> O3[v2 pods]
  end
  subgraph BlueGreen
    B1[Blue v1 live] --> B2[Green v2 tested] --> B3[Switch router]
  end
  subgraph Canary
    C1[5% to v2] --> C2[Watch metrics] --> C3[25%] --> C4[100%]
  end

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments
spec:
  replicas: 6
  revisionHistoryLimit: 10       # how many old revisions stay available for rollback
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2                # at most 2 pods above target
      maxUnavailable: 0          # never dip below capacity
  minReadySeconds: 15
  template:
    spec:
      containers:
        - name: app
          image: registry.example.com/team/payments@sha256:9f8c...
          readinessProbe:
            httpGet: { path: /actuator/health/readiness, port: 8080 }
          lifecycle:
            preStop:
              exec: { command: ["sleep", "10"] }   # grace period to leave the load balancer

preStop fixes a problem many teams discover late: when a pod is deleted, its removal from service endpoints and the termination signal happen at the same time, so in-flight requests reach a dying pod and users see 502s; a short pause closes that window. Turn on server.shutdown=graceful too.

For progressive canary, Argo Rollouts gives you a kind: Rollout with steps setWeight: 5 → pause: { duration: 5m } → analysis → setWeight: 25 → … → setWeight: 100. The analysis step turns a canary from hope into a data-driven decision: a query against your metrics system, and if it crosses the threshold the rollout aborts automatically. But if your dashboard can't show error rate per version, a canary is just a slower rollout — 5% of bad traffic inside 95% healthy traffic is invisible. The real prerequisite is a version label on every metric (see observability).

Feature flags: release vs deployment

The core idea here: deploy means the code is on the server; release means the user sees it.

if (features.isEnabled("new-settlement-engine", customerId)) {
    return newEngine.settle(request);
}
return legacyEngine.settle(request);

Turning off a broken feature takes seconds instead of a full rollout. The cost: every flag is a new execution branch — 10 flags mean 1024 combinations, none fully tested. Rule: every flag gets an owner and an expiry date on day one.

10. Rollback plans

Every deployment must answer three questions before it starts: how will we know it broke? how do we get back? how long does that take?

kubectl rollout history deployment/payments -n prod
kubectl rollout undo deployment/payments -n prod --to-revision=7

Notes: rollout undo only reverts the manifest, and with GitOps the controller re-applies the Git state within seconds — in GitOps, rollback means reverting in Git. Don't set revisionHistoryLimit too low or you have nothing to roll back to. And rollback works only if the previous version is still compatible with the world: schema, message format, API contract.

11. GitOps

GitOps means the desired state is described in Git and an agent inside the cluster continuously reconciles actual state with it. The difference from classic CI/CD is direction: in the push model the pipeline connects to the cluster and runs kubectl apply (so CI holds production credentials); in the pull model a controller inside the cluster reads Git itself, and CI only builds an image and updates one YAML file.

«مدل pull در GitOps» — The pull model in GitOps

flowchart LR
  CI[CI pipeline] -->|push image| Reg[(Registry)]
  CI -->|commit new digest| Cfg[(Config repo)]
  Ctl[GitOps controller in cluster] -->|watch| Cfg
  Ctl -->|pull image| Reg
  Ctl -->|apply| K8s[Cluster state]
  K8s -->|drift detected| Ctl

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payments-prod
spec:
  source:
    repoURL: https://git.example.com/team/deploy-config.git
    targetRevision: main
    path: apps/payments/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: payments
  syncPolicy:
    automated:
      prune: true        # what is deleted from Git is deleted from the cluster
      selfHeal: true     # revert manual changes made in the cluster

Two dominant tools: Argo CD, with a strong UI and ApplicationSet for generating many applications from one template, and Flux, modular controllers with built-in automated image updates (in Argo that is a separate Image Updater).

12. Infrastructure as code with Ansible

IaC means describing infrastructure in versioned files instead of clicks and SSH. Two complementary families: provisioning (creating resources — VMs, networks, clusters; Terraform/OpenTofu territory) and configuration management (configuring what was created; Ansible territory). Ansible is agentless (only SSH and Python on the target) and idempotent.

Hosts are grouped in an inventory file — an [app] group listing app-01.example.com and app-02.example.com — and the playbook targets that group:

- name: Deploy payments service
  hosts: app
  become: true
  serial: 1                    # one at a time — a rolling update on VMs
  vars:
    app_version: "1.4.2"
    app_dir: /opt/payments

  tasks:
    - name: Fetch the artifact from the repository
      ansible.builtin.get_url:
        url: "https://nexus.example.com/repository/releases/payments-{{ app_version }}.jar"
        dest: "{{ app_dir }}/payments-{{ app_version }}.jar"
        checksum: "sha256:{{ app_checksum }}"
        mode: "0640"

    - name: Point the current symlink at the new version
      ansible.builtin.file:
        src: "{{ app_dir }}/payments-{{ app_version }}.jar"
        dest: "{{ app_dir }}/current.jar"
        state: link
      notify: Restart payments

    - name: Wait until the instance reports ready
      ansible.builtin.uri:
        url: "http://127.0.0.1:8080/actuator/health/readiness"
        status_code: 200
      register: health
      retries: 30
      delay: 2
      until: health.status == 200

  handlers:
    - name: Restart payments
      ansible.builtin.systemd_service:
        name: payments
        state: restarted

Three key ideas: serial: 1 updates one machine at a time — a rolling update on VMs; a handler only fires when its task actually changed something; and the until health check before moving on prevents breaking every host at once.

13. DORA: judging a pipeline by numbers

DORA research established four metrics as the indicators of delivery performance — two about speed, two about stability:

Roughly, Elite teams deploy multiple times a day, lead time under a day, change failure rate near 5%, recovery under an hour; Low performers deploy less than monthly, lead time one to six months, failure rate 40%+, recovery in a week to a month (thresholds shift each year).

The key finding is that these four move together: the familiar "either fast or stable" trade-off is false, because a team deploying more often ships smaller changes. Recent reports added complementary indicators — rework rate and reliability — and showed that raising code output without strengthening review and delivery makes stability worse.

14. Pipeline anti-patterns