Handbooks / Microservices / Chapter 10
Teams, Ownership and CI/CD
7 pages · ~5 min✓ Reviewed
Builds on Testing Microservices.
Conway's Law and Team Topologies
1. Conway's Law
- A system's design mirrors the communication structure of the org that builds it
- Inverse Conway manoeuvre: shape teams around the target architecture first
- The architecture then follows the teams
2. Four Team Types
| Team type | Role |
|---|---|
| Stream-aligned | Owns a flow of value |
| Enabling | Coaches other teams |
| Complicated-subsystem | Deep specialists |
| Platform | Provides self-service internals |
3. Interaction Modes
| Mode | Nature |
|---|---|
| Collaboration | Temporary, high-bandwidth |
| X-as-a-Service | Clear API, low contact |
| Facilitating | Coach and unblock |
4. Common Mistake
Teams split by layer (UI / backend / DB)
Every feature crosses three teams and creates hand-offs. Own a slice of value instead.
Service Ownership and Boundaries
1. You Build It, You Run It
- You build it, you run it: the owning team covers the whole life of its service
- Exactly one owning team per service
- Shared ownership = no ownership
- Design
- Deploy
- On-call
- Incidents
- Cost
2. Artefacts and Load
- Service catalogue entry
- On-call rotation
- Runbook
- SLOs
- A named contact
- Cognitive load: own only what the team can fully understand and operate
- Typical limit: 1-3 services per team
3. Hidden Coupling
- Shared database across teams: a schema change needs cross-team sign-off
- Shared library across teams: an upgrade forces coordinated releases
Mistake
Monorepo vs Polyrepo
1. Two Repo Layouts
| Monorepo | Polyrepo | |
|---|---|---|
| Shape | Many services in one repo | One repo per service |
| Gives | Atomic cross-service commits, one dependency version set, easy refactors | Clear ownership, independent access control and release cadence |
| Shared code | Easy to share, needs scaling tooling | Isolated, risks version drift of shared libraries |
| Cross-service change | One commit | Coordinated PRs across repos |
2. Monorepo Tooling
- CODEOWNERS gives per-path review: each folder has its owning team
- Affected-only builds: build and test just what a change touches
- Tools: Bazel, Nx, Turborepo
text
/services/orders/ @acme/orders-team /libs/auth/ @acme/platform-team
CODEOWNERS: path, then owning team
3. Common Mistakes
Independent Pipelines per Service
1. One Pipeline per Service
- Each service has its own build, test, deploy pipeline
- A service can ship alone, without releasing the others
- Monorepo trigger: path filters, so only the changed service builds
yaml
on:
push:
paths: ['services/orders/**']GitHub Actions: runs only when orders changes
2. Safe Independent Deploys
- Needs backward-compatible APIs, so old consumers keep working
- Add contract tests (e.g. Pact) so consumers don't break
- Use immutable artefacts: one image tag per commit SHA
- CommitSHA abc123
- Build imagetag = SHA
- Stagingsame artefact
- Prodsame artefact
3. Mistakes
- A lockstep release train forces services to deploy together
- One shared pipeline for all services does the same
- Result: a distributed monolith
Interview Point
Why can one service deploy alone? Own pipeline, compatible APIs, contract tests. Same SHA-tagged artefact goes staging to prod.
Deployment Frequency and Platform Teams
1. DORA Metrics
| Metric | Measures | Better |
|---|---|---|
| Deployment frequency | How often you ship | Higher |
| Lead time for changes | Commit to production | Shorter |
| Change failure rate | Deploys that cause failure | Lower |
| Time to restore service | Recovery after an incident | Shorter |
- Elite teams deploy on demand, many times a day
- They keep a low change failure rate
- Small batches lower the risk of each deploy
2. Enablers of Frequent Deploys
- Trunk-basedshort-lived branches
- Feature flagsship dark
- Automated testsfast feedback
- Canary / blue-greensafe rollout
3. Platform Teams
Team and Delivery Cheat Sheet
1. Teams Shape Systems
- Conway's law: org structure becomes architecture
- Inverse Conway: shape teams first, design on purpose
- Modes: collaboration, X-as-a-Service, facilitating
| Team type | Job |
|---|---|
| Stream-aligned | Owns a flow of value |
| Enabling | Coaches others |
| Complicated-subsystem | Deep specialists |
| Platform | Self-service internals |
2. Ownership and Repos
- One team per service; you build it, you run it
- Needs catalogue entry, on-call, runbook, SLOs
| Monorepo | Polyrepo | |
|---|---|---|
| Strength | Atomic change, shared code | Isolation, own cadence |
Check yourself
A company has separate UI, backend and database teams. Adding one field to a form needs all three. What does Conway's law predict, and what is the fix?
- Layered architecture with hand-offs between the three teams, so every feature is slow.
- Reorganise into stream-aligned teams that each own a feature end to end (inverse Conway).
Orders and Billing teams share one database. Billing renames a column in its own deploy. What happens?
- Orders breaks at runtime: hidden coupling, and the change needed cross-team coordination.
- Fix: each service owns its data and exposes an API.
A monorepo pipeline has on: push with no paths filter. A one-line change lands in services/orders. What runs?
- Every service's build and tests run, not just orders.
- Fix:
paths: ['services/orders/**']so only the changed service builds.