A software-defined pipeline declares automation behavior as versioned code owned by the team, with source-triggered CI pipelines stored beside the code they test. section 6.2.2
Build the pattern around explicit ownership and controlled change:
- Keep CI and deployment pipeline code in the team’s repository rather than relying on GUI configuration. section 6.2.2
- Extract common build and test steps into shared code, and manage internal pipeline libraries with integration tests and versioned releases. section 6.2.2
- Introduce shared-pipeline changes through intentional version updates; fork shared code when necessary changes are delayed. section 6.2.2
A team-owned delivery pipeline
A team stores its CI definition beside application code, references a versioned internal library for common build and test steps, and deliberately upgrades when that library changes. The team can fork the library instead of waiting for another group, avoiding blocked developers and unexpected breaking changes. section 6.2.2
