The CD Pipeline Manifesto

1. Single Source of Truth

What was damaged:

Pipeline definitions are scattered across multiple tools (GitHub Actions, Jenkins, ArgoCD, Kubernetes) and environments. This fragmentation leads to confusion, configuration drift, and duplication of effort.

Your pipeline needs a single, versioned source of truth—a unified definition that’s easy to understand, review, and evolve from.

2. Reusable, type-safe and composable

What was damaged:

Pipelines are often duplicated between projects, resulting in redundant code and maintenance overhead. Even if the core logic is the same, every pipeline for every project has to be rewritten. Without types, it’s difficult to put pipelines together.

Build pipelines like software. Modular, reusable components make it easy for teams to share jobs, templates, and logic. Utilize an appropriate type-safe language to ensure safety and composition.

3. Pipelines should be dynamic and flexible

What was damaged:

Most pipelines today are static and cannot adapt to dynamic inputs, environment changes, or complex dependencies. Conditional logic and execution-time decisions are combined (eg using conditions in shell scripts or YAML).

Pipelines require the power of real code: loops, conditionals, runtime logic, standard libraries, and more. Flexible pipelines can dynamically adapt to your team’s needs without hacking.

4. Transparent, visual and debuggable pipeline

What was damaged:

YAML and text-based pipelines are opaque. Visualizing workflows, understanding dependencies, and debugging failures is tedious and error-prone. With so many tools and services involved, it’s not easy to provide a view of the entire process.

Pipelines should be transparent, visual, and debuggable. Teams should be able to view processes, understand logic, and easily debug issues through a single pane of glass.

5. Pipelines are constantly evolving, and changes can lead to instability

What was damaged:

Whether the boundaries between components in a pipeline are clear or not, they exist and are constantly changing. When a component changes, failing to identify everything that needs to be updated is an easy mistake to make. For other software, automated tests are built to prevent regressions and unexpected behavior. Our pipeline definition should achieve the same effect.

Use complete modern programming languages ​​and their existing testing frameworks and tools.

6. The feedback loop is slow, resulting in slow recovery and slow progress.

What was damaged:

Many people are familiar with the pain of a slow remote build system or release pipeline. Small fixes or improvements have to be made, added, committed, pushed, waiting to be built, waiting to be released, waiting to be deployed, etc., and it all adds up. Often, due to limitations of the tools we use, this is the only way to know if a change is working as expected

Ability to run and debug the entire end-to-end process on our local computer with minimal configuration and no unexpected side effects.