Unit of Flow
Introduction
The Unit of Flow is a conceptual framework that divides Continuous Delivery into four discrete, interconnected components.
Understanding these components and their relationships is essential for implementing an effective CD Model.
The Four Components
Trunk
The version-controlled repository where code lives.
Implemented as a Git repository following trunk-based development, it contains "everything as code" and represents the single source of truth.
Can be a polyrepo (one deployable module) or monorepo (multiple deployable modules).
See Trunk for monorepo vs polyrepo patterns.
Deployable Module
The discrete body of work that is built, tested, and delivered as a single unit.
Composed of immutable artifacts with its own version number.
Types include runtime systems (services, apps) and versioned components (libraries, containers).
See Deployable Modules for types, versioning, and artifact management.
Deployment Pipeline
The automated process that validates and delivers changes through the CD Model's 12 stages.
Triggered by trunk commits, it builds artifacts, runs tests, and deploys to production.
Each deployable module has its own pipeline instance.
See Pipeline for triggers, stages, and evidence collection.
Live
The destination where released software serves consumers.
- For services, this is production.
- For versioned components, this is a package registry.
Provides feedback loops that influence future development.
See Live for destinations by module type and rollback strategies.
Relationships
The four components connect in a continuous flow:
Trunk Contains Deployable Modules
- Polyrepo: One trunk = one deployable module
- Monorepo: One trunk = multiple deployable modules
Each Deployable Module Has a Pipeline
- Polyrepo: One pipeline per repository
- Monorepo: Multiple pipelines, one per module
Pipeline Delivers to Live
The pipeline validates changes and delivers immutable artifacts to production or registries.
Live Feedback Influences Trunk
Monitoring, incidents, and user behavior create feedback that drives changes to trunk.
Common Patterns
Single Service (Polyrepo)
Use when: Service is independent, team owns entire service, clear boundaries.
Multi-Service Platform (Monorepo)
Use when: Services share code, need atomic cross-service changes, small-medium team.
Microservices (Multiple Polyrepos)
Use when: Services loosely coupled, multiple teams with separate ownership, independent deployment.
Next Steps
- Trunk - Monorepo vs polyrepo patterns
- Deployable Modules - Types, versioning, artifacts
- Pipeline - Automation and stages
- Live - Production and registries
- CD Model Overview - Complete 12-stage framework
References
Tutorials | How-to Guides | Explanation | Reference
You are here: Explanation — understanding-oriented discussion that clarifies concepts.