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.
7 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.
Gates marked with ▲ are enhanced by AI - the AI shifts detection earlier or catches issues that rule-based tools miss. See the Systemic Defect Fixes catalog for details.
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 | |
| Unit tests | Logic errors, unintended side effects, edge cases | Change & Complexity | Required |
| Timeout enforcement checks | Missing timeout and deadline enforcement | Performance & Resilience | |
| ▲ AI semantic code review | Logic errors, missing edge cases, subtle injection vectors beyond pattern matching | Process & Deployment, Security & Compliance |
CI Stage 1: Build and Fast Tests < 5 min
These run on every commit to trunk.
| Gate | Defect Sources Addressed | Catalog Section | Pre-Feature |
|---|---|---|---|
| All pre-commit gates | Re-run in CI to catch anything bypassed locally | See Pre-commit Gates | Required |
| Compilation / build | Build reproducibility, dependency resolution | Dependency & Infrastructure | 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 | |
| ▲ AI change impact analysis | Semantic blast radius of changes; unintended side effects beyond syntactic dependencies | Change & Complexity | |
| ▲ AI vulnerability reachability analysis | Correlate CVEs with actual code usage paths to prioritize exploitable risks over theoretical ones | Security & Compliance | |
| Stage duration warning | Warn if Stage 1 exceeds 10 minutes; slow fast-feedback loops mask defects and delay trunk integration | Process & Deployment |
CD Stage 1: 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 | |
| ▲ AI boundary coverage analysis | Integration boundaries missing contract tests; semantic service relationship mapping | Testing & Observability Gaps | |
| ▲ AI behavioral assumption detection | Undocumented assumptions at service boundaries that contract tests don’t cover | Integration & Boundaries |
CD Stage 2: 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 | |
| ▲ AI edge case test generation | Untested boundaries and error conditions identified from code path analysis | Testing & Observability Gaps | |
| ▲ AI authorization path analysis | Missing authorization checks and privilege escalation patterns in code paths | Security & Compliance | |
| ▲ AI resilience review | Single points of failure and missing fallback paths in architecture | Performance & Resilience | |
| ▲ AI regulatory mapping | Map regulatory requirements to implementation artifacts; flag uncovered controls | Security & Compliance |
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 | Implementation does not match acceptance criteria | 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 | |
| ▲ AI intent alignment review | Acceptance criteria vs. user behavior data misalignment; specs that meet the letter but miss the intent | Product & Discovery |
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 | |
| ▲ AI change risk scoring | Automated risk assessment from change diff, deployment history, and blast radius analysis | Process & Deployment |
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.
Gates marked with ▲ correspond to catalog entries where AI shifts detection earlier than current rule-based automation. For expert agent patterns that implement these gates in an agentic CD context, see ACD Pipeline Enforcement.
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.