Lesson 15 / 25

Independent Build and Deployment

Set up per-service pipelines, containers and environments for independent releases.

Independent deployability is engineered

Each service needs its own pipeline: build, unit tests, contract tests, container image, security scan, deploy to staging, automated checks, progressive rollout to production. Package services as containers with a standard base image and health endpoints, and run them on a platform such as Kubernetes, a managed container service or serverless containers. Repositories can be one repo per service (clear ownership, independent history) or a monorepo with tooling that builds only what changed (easier cross-cutting changes, shared tooling); both work. Shared libraries are fine for technical concerns like logging, but sharing domain model libraries couples deployments. A platform team often provides templates (a "paved road") so a new service gets pipeline, observability and security defaults on day one. Test independence by asking: can this team deploy on a Friday afternoon without telling anyone?

A per-service pipeline outline

Every service follows the same stages; only the service-specific tests differ.

name: checkout-service
on:
  push:
    paths: ["services/checkout/**"]       # monorepo: build only when this service changes
jobs:
  build-test-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make -C services/checkout test           # unit + component tests
      - run: make -C services/checkout contract-test  # verify consumer contracts
      - run: make -C services/checkout image TAG=${{ github.sha }}
      - run: make -C services/checkout scan TAG=${{ github.sha }}
      - run: make -C services/checkout deploy ENV=staging TAG=${{ github.sha }}
      - run: make -C services/checkout smoke ENV=staging
      - run: make -C services/checkout canary ENV=prod TAG=${{ github.sha }}

Shared domain libraries recreate the monolith

If ten services depend on a shared shop-domain library and a change to it requires redeploying all ten, you have a distributed monolith. Share contracts (schemas), not domain code.

Quick check: Which practice undermines independent deployment?

  • A pipeline per service
  • Contract tests
  • A shared domain-model library that every service must upgrade together
  • Container images with health endpoints
Answer

A shared domain-model library that every service must upgrade together — Shared domain libraries force coordinated releases across services.