A single pipeline in a single repository is a script. Fifty pipelines across a company are a system, and they need to be designed like one: shared components, consistent stages, central policy and local flexibility. This lesson sets the architecture before any configuration is written.
Stages every pipeline shares
Validate, build, test, package, publish, deploy, verify. Every service passes through the same stages in the same order, even when the contents differ. This consistency is what makes fleet-wide policy and observability possible.
Shared templates and versioning
Pipeline logic lives in a central, versioned library that repositories reference. Services pin a version and upgrade deliberately. Changes to the library go through review and a canary set of repositories before general release.
Separation of concerns
The continuous integration pipeline proves a commit is sound. The delivery pipeline moves a proven artefact through environments. Coupling them makes every deploy rebuild and every rebuild redeploy.
Common pitfall
Copying a pipeline file into each new repository. Within a year there are forty variants and no way to change them all.
Action Step
Create a pipeline template repository with the seven shared stages as reusable components, and a sample service that references a pinned version. This is the reference implementation the whole course extends.
This course is vendor-independent: it is not affiliated with, endorsed by or accredited by any tool vendor or certification body, names products only for identification, and issues no credential. Verify current documentation before applying anything in production.