Single Team, Single Deployable
A linear pipeline pattern for a single team owning a modular monolith.
Pipeline Reference Architecture
Pipeline reference architectures for single-team, multi-team, and distributed service delivery, with quality gates sequenced by defect detection priority.
5 minute read
This section defines quality gates sequenced by defect detection priority and three pipeline patterns that apply them. Quality gates are derived from the Systemic Defect Fixes catalog and sequenced so the cheapest, fastest checks run first.
Gates marked with [Pre-Feature] must be in place and passing before any new feature work begins. They form the baseline safety net that every commit runs through. Adding features without these gates means defects accumulate faster than the team can detect them.
Quality Gates in Priority Sequence
The gate sequence follows a single principle: fail fast, fail cheap. Gates that catch the most common defects with the least execution time run first. Each gate listed below maps to one or more defect sources from the catalog.
Pre-commit Gates
These run on the developer’s machine before code leaves the workstation. They provide sub-second to sub-minute feedback.
| Gate | Defect Sources Addressed | Catalog Section | Pre-Feature |
|---|---|---|---|
| Linting and formatting | Code style consistency, preventable review noise | Process & Deployment | Required |
| Static type checking | Null/missing data assumptions, type mismatches | Data & State | Required |
| Secret scanning | Secrets committed to source control | Security & Compliance | Required |
| SAST (injection patterns) | Injection vulnerabilities, taint analysis | Security & Compliance | Required |
| Race condition detection | Race conditions (thread sanitizers, where language supports it) | Integration & Boundaries | |
| Accessibility linting | Missing alt text, ARIA violations, contrast failures | Product & Discovery | |
| Timeout enforcement checks | Missing timeout and deadline enforcement | Performance & Resilience |
CI Stage 1: Build and Fast Tests < 5 min
These run on every commit to trunk.
| Gate | Defect Sources Addressed | Catalog Section | Pre-Feature |
|---|---|---|---|
| Compilation / build | Build reproducibility, dependency resolution | Dependency & Infrastructure | Required |
| Unit tests | Logic errors, unintended side effects, edge cases | Change & Complexity | Required |
| Dependency vulnerability scan (SCA) | Known vulnerabilities in dependencies | Security & Compliance | Required |
| License compliance scan | License compliance violations | Security & Compliance | |
| Code complexity and duplication scoring | Accumulated technical debt | Change & Complexity |
CI Stage 2: Integration and Contract Tests < 10 min
These validate boundaries between components.
| Gate | Defect Sources Addressed | Catalog Section | Pre-Feature |
|---|---|---|---|
| Contract tests | Interface mismatches, wrong assumptions about upstream/downstream | Integration & Boundaries | Required |
| Schema migration validation | Schema migration and backward compatibility failures | Data & State | Required |
| Infrastructure-as-code drift detection | Configuration drift, environment differences | Dependency & Infrastructure | |
| Environment parity checks | Test environments not reflecting production | Testing & Observability Gaps |
CI Stage 3: Broader Automated Verification < 15 min
These run in parallel where possible.
| Gate | Defect Sources Addressed | Catalog Section | Pre-Feature |
|---|---|---|---|
| Mutation testing | Untested edge cases and error paths, weak assertions | Testing & Observability Gaps | |
| Performance benchmarks | Performance regressions | Performance & Resilience | |
| Resource leak detection | Resource leaks (memory, connections) | Performance & Resilience | |
| Security integration tests | Authentication and authorization gaps | Security & Compliance | |
| Compliance-as-code policy checks | Regulatory requirement gaps, missing audit trails | Security & Compliance | |
| SBOM generation | License compliance, dependency transparency | Security & Compliance | |
| Automated WCAG compliance scan | Full-page rendered accessibility checks with browser automation | Product & Discovery |
Acceptance Tests < 20 min
These validate user-facing behavior in a production-like environment.
| Gate | Defect Sources Addressed | Catalog Section | Pre-Feature |
|---|---|---|---|
| Functional acceptance tests | Building the wrong thing, meets spec but misses intent | Product & Discovery | |
| Load and capacity tests | Unknown capacity limits, slow response times | Performance & Resilience | |
| Chaos and resilience tests | Network partition handling, missing graceful degradation | Performance & Resilience | |
| Cache invalidation verification | Cache invalidation errors | Data & State | |
| Feature interaction tests | Unanticipated feature interactions | Change & Complexity |
Production Verification
These run during and after deployment. They are not optional - they close the feedback loop.
| Gate | Defect Sources Addressed | Catalog Section | Pre-Feature |
|---|---|---|---|
| Health checks with auto-rollback | Inadequate rollback capability | Process & Deployment | |
| Canary or progressive deployment | Batching too many changes per release | Process & Deployment | |
| Real user monitoring and SLO checks | Slow user-facing response times, product-market misalignment | Performance & Resilience | |
| Structured audit logging verification | Missing audit trails | Security & Compliance |
Pre-Feature Baseline
These gates must be active before starting feature work
Without these gates passing on every commit to trunk, defects accumulate faster than the team can detect them. If any are missing, add them before writing new features. The Foundations phase covers how to establish this baseline.
- Linting and formatting
- Static type checking
- Secret scanning
- SAST for injection patterns
- Compilation / build
- Unit tests
- Dependency vulnerability scan
- Contract tests at every integration boundary
- Schema migration validation
Pipeline Patterns
These three patterns apply the quality gates above to progressively more complex team and deployment topologies. Most organizations start with Pattern 1 and evolve toward Pattern 3 as team count and deployment independence requirements grow.
- Single Team, Single Deployable - one team owns one modular monolith with a linear pipeline
- Multiple Teams, Single Deployable - multiple teams own sub-domain modules within a shared modular monolith, each with its own sub-pipeline feeding a thin integration pipeline
- Independent Teams, Independent Deployables - each team owns an independently deployable service with its own full pipeline and API contract verification
Mapping to the Defect Sources Catalog
Each quality gate above is derived from the Systemic Defect Fixes catalog. The catalog organizes defects by origin - product and discovery, integration, knowledge, change and complexity, testing gaps, process, data, dependencies, security, and performance. The pipeline gates are the automated enforcement points for the systemic prevention strategies described in the catalog.
When adding or removing gates, consult the catalog to ensure that no defect category loses its detection point. A gate that seems redundant may be the only automated check for a specific defect source.
Further Reading
For a deeper treatment of pipeline design, stage sequencing, and deployment strategies, see Dave Farley’s Continuous Delivery Pipelines which covers pipeline architecture patterns in detail.
Related Content
- Systemic Defect Fixes - the defect source catalog that informs gate selection
- Pipeline Architecture - how to evolve pipeline architecture from entangled to loosely coupled
- Deterministic Pipeline - ensuring the pipeline produces consistent results
- Single Path to Production - why all changes must flow through one pipeline
- Immutable Artifacts - build once, deploy everywhere
- Phase 2: Pipeline - the migration phase that establishes the pipeline
- Slow Pipelines - what happens when pipeline architecture is not optimized
- ACD - additional pipeline constraints when AI agents contribute changes
Multiple Teams, Single Deployable
A sub-pipeline pattern for multiple teams contributing domain modules to a shared modular monolith.
Independent Teams, Independent Deployables
A fully independent pipeline pattern for teams deploying their own services in any order, with API contract verification replacing integration testing.