# Independent Build and Deployment — Monolith vs Microservices

Source: https://www.skillbyai.com/en/monolith-microservices/i-delivery

> 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.

```yaml
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.

**Quiz:** Which practice undermines independent deployment?

- [ ] A pipeline per service
- [ ] Contract tests
- [x] 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.