How do I standardize pipelines across multiple repos?

A good way to standardize pipelines across multiple repos is to make the pipeline logic reusable and centrally managed, while keeping each repo’s config thin and repo-specific.

Common approaches

1. Shared pipeline templates

Create a central repo that contains reusable pipeline templates or workflow files, then have each repo reference them.

• Pros: Easy to roll out updates centrally
• Cons: Some CI systems have limitations on template flexibility

Examples:

• GitHub Actions: reusable workflows + composite actions
• GitLab CI: include: shared templates
• Azure DevOps: YAML templates
• Jenkins: shared libraries

---

2. Shared build/test/deploy scripts

Put the actual logic in a shared library or package, and keep pipeline YAML minimal.

Example structure:

• ci-scripts/
  • build.sh
  • test.sh
  • deploy.sh

Each repo calls the same scripts from a versioned package or submodule.

• Pros: Works across different CI platforms
• Cons: Still need per-repo pipeline wiring

---

3. Pipeline-as-code with a standard repo convention

Define a standard layout and behavior across repos:

• same config file names
• same stages
• same environment variable conventions
• same artifact naming
• same quality gates

Then create a “starter” or “golden” repo template for new services.

• Pros: Enforces consistency
• Cons: Doesn’t automatically update old repos unless migrated

---

4. Central orchestration platform

If you have many repos, consider using:

• a monorepo
• or a central CI orchestrator that triggers repo-specific jobs

Useful when pipelines need coordinated releases or dependency awareness.

---

What to standardize first

Focus on the parts that create the most drift:

• Stages: lint → test → build → security scan → deploy
• Tool versions: Node/Python/Java/.NET, etc.
• Environment variables and secrets naming
• Artifact naming and storage
• Caching strategy
• Branch/tag/release rules
• Approval and promotion rules
• Logging and notifications
• Fail-fast behavior and retries

---

Recommended pattern

For most orgs, the best balance is:

1. Central reusable pipeline templates
2. Central shared scripts
3. Repo-level config files with only overrides
4. Version the templates so changes don’t break all repos at once

Example idea:

• pipeline-template@v1
• repos consume v1
• update a few repos to v2
• deprecate v1 later

---

Practical governance tips

• Create a reference pipeline as the source of truth
• Document required repo inputs and expected outputs
• Add linting/validation for pipeline configs
• Use automated updates where possible
• Track adoption with a checklist or registry
• Maintain backward-compatible versions of templates

---

Example pattern

A repo’s pipeline config might only define:

• service name
• language/runtime
• deployment environment
• whether to run integration tests

Everything else comes from the shared template.

---

If you want, I can also show you:

1. a GitHub Actions example,
2. a GitLab CI example, or
3. a recommended folder structure for a centralized pipeline repo.