Pipeline Templates: Reusable CI/CD Building Blocks

WHY IT EXISTS: As organizations scale, CI/CD configurations become repetitive and hard to manage. Copy-pasting YAML across hundreds of repositories leads to inconsistencies, makes updates difficult, and prevents standardization of best practices like security scanning. Pipeline templates solve this by centralizing reusable logic.

THE MENTAL MODEL: Think of a pipeline template as a function or a library for your CI/CD system. Instead of writing the same logic to run a linter or deploy to staging in every project's pipeline file, you call a pre-built, versioned template. This template can accept parameters (inputs) to customize its behavior, just like a function takes arguments.

HOW IT WORKS: A template is typically a YAML file defining a set of CI/CD jobs or steps. These templates are stored in a dedicated repository, often called a "component project." This project acts as a container for one or more related templates, which are versioned together using Git tags. Other projects can then import a specific version of a template. For example, a project's main pipeline file might include a reference like component: my-org/templates/security-scan@v1.2.0. The CI/CD runner fetches the template from that version and merges it into the project's pipeline.

WHEN TO USE IT: Use templates for any CI/CD logic that is repeated across multiple projects. This is perfect for enforcing standards, such as requiring all services to run a specific security scanner, use a standard build process, or deploy using a consistent set of steps. They are also great for creating a catalog of optional, pre-approved pipeline tasks that developers can easily discover and use.

WHEN NOT TO USE IT: Avoid creating templates for logic that is truly unique to a single project. Over-abstracting highly specific deployment steps can make the template complex and brittle. If a "reusable" template ends up with dozens of inputs and conditional logic to handle edge cases for different projects, a simpler, project-specific configuration is better.

ONE CANONICAL EXAMPLE: A platform team creates a repository to host a secret-detection template. The template is defined in templates/secret-detection.yml and contains the YAML for a job that runs a scanner. The team tests it and releases version v1.0.0. Now, any other team can add it to their CI/CD configuration by including the component and referencing v1.0.0. When the platform team improves the scanner and releases v1.1.0, other projects are unaffected until they explicitly update their configuration to use the new version, preventing unexpected breakages.