Standardize in layers. Start with one versioned pipeline template per CI system, a shared runner pool, and short-lived cloud credentials, then add policy checks and a standard deploy step, and run it all as an inner-sourced repository owned by a rotating guild of one engineer per team.
Disclosure: Control Plane publishes this guide.
TL;DR
Standardize in layers, starting with versioned templates, shared runners, and OIDC credentials.
- Guild model. One champion per team forms a guild that maintains shared templates in a repository anyone can contribute to. Rotate the primary maintainer each quarter.
- Templates first. One reusable pipeline template per CI system covering build, test, scan, and deploy gives the most leverage.
- Versioning. Tag template releases with semantic versions so teams pin a version and upgrade on their own schedule.
- Shared runners. One autoscaling runner pool with labels for size and trust level replaces per-team runner fleets.
- Short-lived credentials. OIDC federation between the CI system and each cloud replaces long-lived cloud keys stored as CI secrets.
- Policy checks. Linting, scanning, and policy gates live inside the template, so enforcement runs on every pipeline without a reviewer.
- Standard deploy step. A shared deploy action health-gates every release and promotes the same artifact between environments.
- Metrics. Track lead time for changes, deployment frequency, change failure rate, failed deployment recovery time, and pipeline duration before and after adoption.
- Where Control Plane fits. Control Plane gives every team the same deploy target and a health-gated deploy command, across every region and cloud in a Control Plane Global Virtual Cloud (GVC).
How can we standardize CI runners and deployment pipelines without a platform team?
Treat the CI/CD standard as an inner-sourced product. A small group of engineers from different teams maintains a shared repository of pipeline templates, runner configuration, and deploy actions. Each team consumes the templates the way it consumes an open-source library: pin a version, call the template from its own pipeline file, and add only the steps specific to its service.
Enforcement comes from convenience. When the template gives a team builds, tests, security scans, short-lived cloud credentials, and a health-gated deploy for a few lines of configuration, a hand-written pipeline becomes the slower option.
Decide early what stays with each team. Teams own their test suites, feature flags, service-specific configuration, and the decision of when to ship. The shared template owns how to build, how to authenticate, how to scan, and how to deploy. That boundary keeps the template useful without turning the guild into a bottleneck. The guide to production-grade infrastructure without a platform team covers the rest of the stack.
What should you standardize first?
| Order | What to standardize | Mechanism | Owner | Effort |
|---|---|---|---|---|
| 1 | Reusable pipeline template per CI system | Reusable workflow, CI/CD component, shared library, or orb | Guild | Medium |
| 2 | Versioning and release of templates | Semantic version tags and a changelog per release | Guild maintainer | Low |
| 3 | Shared runner pool with labels | Autoscaling runners on Kubernetes or cloud VMs, labeled by size and trust level | A guild champion who owns runner infrastructure | High |
| 4 | Short-lived cloud credentials | OIDC federation from the CI system to each cloud account | Security champion with the guild | Medium |
| 5 | Curated base images and dependency caching | Maintained base images in a shared registry; caches in the runner pool, scoped by trust level so fork and untrusted jobs never write to caches that deploy jobs read | Guild, with each team adding app layers | Medium |
| 6 | Security and policy checks in the template | actionlint (GitHub Actions), OPA or Conftest policies, repository rulesets, secret scanning, SAST and dependency scanners, artifact signing with provenance | Security champion | Medium |
| 7 | A standard deploy step and deploy target | One deploy action per target that waits for health checks | Guild | High |
| 8 | Environment and promotion rules | Promote the same artifact from staging to production behind approvals or automated checks | Each team, using template gates | Medium |
| 9 | Pipeline metrics | CI analytics exported to a shared dashboard | Guild maintainer | Low |
Effort ratings are editorial judgments and depend on how many CI systems and clouds you run.
How do you share pipelines and runners in each CI system?
| CI system | Reusable pipeline mechanism | Version pinning | Shared runner option | Short-lived cloud credentials |
|---|---|---|---|---|
| GitHub Actions | Reusable workflows and composite actions | Pin by tag or commit SHA | Actions Runner Controller on Kubernetes, or larger hosted runners | OIDC tokens, requested with the id-token write permission |
| GitLab CI/CD | include and the CI/CD components catalog | Pin component versions | Group or instance runners with autoscaling | ID tokens for OIDC federation |
| Jenkins | Shared libraries | Pin library versions in the Jenkinsfile | Kubernetes agents through the Kubernetes plugin | OIDC ID tokens through the OpenID Connect Provider plugin |
| CircleCI | Orbs | Pin orb versions | Self-hosted runners | OIDC tokens |
Teams on more than one CI system can keep one template per system that runs the same stages and calls the same deploy step, so the deploy target becomes the shared layer.
Who owns the standards without a platform team?
A guild replaces the platform team with a light, cross-team group.
- One champion per team. Each team names one engineer who reviews template pull requests, triages issues, and represents the team’s needs. One champion also acts as security champion for credentials and policy checks.
- A rotating primary maintainer. One champion owns releases, the changelog, and tie-breaks for a quarter, then hands off so no one becomes a bottleneck.
- A public changelog. Every release says what changed and whether teams need to act, posted where every team will see it.
- Pull requests from anyone. Any engineer can propose a change; champions review and merge.
- A review rule for opt-outs. A team that deviates records why and gets one champion’s review, which shows the guild what the template is missing.
- A protected time budget. Leadership sets aside a fixed number of hours per champion each week so template work has scheduled time.
The guide to developer self-service with guardrails covers how to give teams autonomy inside these limits.
How do you standardize CI runners?
- Run one shared autoscaling pool. Actions Runner Controller scales GitHub Actions runners on Kubernetes, GitLab Runner runs jobs as pods with its Kubernetes executor or autoscales VMs with the Docker Autoscaler and Instance executors (Docker Machine is deprecated), and Jenkins starts agents on Kubernetes through its plugin.
- Label runners by size and trust level. Teams pick labels such as small, large, trusted, and untrusted, and the guild maps labels to machine types.
- Make runners ephemeral by default. Route fork and outside-contributor jobs to hosted runners or an isolated ephemeral pool with no secrets, so no credentials or state carry over.
- Pin and verify what pipelines pull in. Pin third-party actions, orbs, and images by commit SHA or digest, let Renovate or Dependabot propose upgrades, run secret scanning on every push, and have the template sign artifacts and attach SLSA provenance.
- Separate production deploy runners. Only labeled deploy runners can reach production credentials and targets, isolated from general CI by labels and network policy.
- Show cost per team. Tag runner usage by team or repository and publish it on a shared dashboard so teams see their consumption.
The policy-as-code guide covers writing the policy checks the template runs.
How do you standardize the deploy step?
- One deploy action per target. A single reusable action, component, or library step takes the image tag, environment, and variables as inputs.
- Health-gated deploys. The deploy step waits until the new version passes health checks and fails the pipeline if it does not, so broken releases do not report success.
- Build once, promote the same artifact. Staging and production deploy the same image with different configuration, behind manual approval, automated checks, or both.
- Roll back by redeploying a known version. When deploys are idempotent and health-gated, rollback is a deploy of the last good image tag. Keep database migrations backward compatible (expand, then contract) so the previous version still runs.
The guide to automating app deployment with IaC, CI/CD, and GitOps shows a full reference stack, and the comparison of Argo CD and Flux covers pull-based deploys for teams on Kubernetes.
How do you get teams to adopt the standard?
- Make the template the fastest path. A team that adopts it should delete pipeline code and gain caching, scanning, credentials, and health-gated deploys it did not have.
- Migrate one team first. Start with a simple pipeline, record setup time and lines of pipeline code before and after, and use that team as the reference.
- Measure before and after. Compare the delivery metrics for migrated teams and share the results with every team.
- Deprecate old pipelines with dates. Once the template is proven, announce a deprecation date with a generous window, migration guides, and office hours.
- Allow documented opt-outs. A machine learning training pipeline and a web service deploy differ, so cover the common case and record the exceptions.
How Control Plane fits
Control Plane is the unbreakable platform for running production workloads. It runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, Azure, and Oracle Cloud Infrastructure (OCI), VM workloads on locations joined through Control Plane’s Managed Kubernetes, and workloads on Kubernetes clusters you already run or your own machines, including on premises, active-active across regions and clouds. Control Plane handles Day 2 operations for you, including autoscaling, built-in observability, and security.
For CI/CD, Control Plane standardizes the deploy target itself. A Global Virtual Cloud (GVC) is Control Plane’s named set of locations; a workload deployed to a GVC runs in every location of that GVC from one definition, so one deploy step covers every region and cloud in it, with no per-region logic in the template. In CI/CD, the cpln apply command with the ready flag waits until the workload is healthy before the pipeline continues, which gives every team the same health-gated deploy step.
Every Control Plane org has a private image registry, and the cpln CLI can build and push images to it. Pipelines authenticate to Control Plane with service account keys passed through the CPLN_TOKEN environment variable, and policies can grant each service account least-privilege permissions on specific resources, so you can limit each team’s pipeline to its own workloads. Control Plane’s Universal Cloud Identity lets running workloads reach AWS, GCP, and Azure services through one identity, with no long-lived cloud keys in your code, which pairs with OIDC federation in the CI system for build-time cloud access.
The CLI, console, Terraform and Pulumi providers, and the Control Plane MCP server all work through the same Control Plane API, so one team’s deploy template can call the CLI while another uses Terraform. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.
Teams still choose and run their CI system, templates, runners, and tests. Teams weighing Kubernetes can read how to get Kubernetes benefits without a platform team.
FAQ
Each answer covers one decision in standardizing CI/CD.
How can we standardize CI runners and deployment pipelines across teams without a platform engineering team?
Run CI/CD as an inner-sourced product owned by a guild of one champion per team. Start with versioned templates, shared runners, and OIDC credentials, then add policy checks and a health-gated deploy step.
What is a golden path pipeline?
A golden path pipeline is a prebuilt CI/CD template that encodes your organization’s way to build, test, scan, and deploy. Teams start from it and add only service-specific steps, and it stays the default because it is the easiest route to production.
How do GitHub Actions reusable workflows help standardize CI?
They let one repository define a complete workflow that other repositories with access call with inputs and secrets. Callers pin the workflow to a tag or commit SHA, so they control upgrades, and composite actions package individual steps inside it.
How do you version shared CI templates?
Tag releases of the template repository with semantic versions and publish a changelog for each. Teams pin a version in their pipeline file, test an upgrade on a branch, and merge when it passes, which decouples template releases from team release schedules.
Should CI runners be shared across teams?
Usually yes. A shared autoscaling pool cuts duplicated operations, uses capacity better, and gives the guild one place to enforce security. Label runners by size and trust level, isolate production deploy runners, and reserve a labeled subset for workloads with dedicated-compute requirements.
How do you give CI pipelines cloud access without long-lived keys?
Use OIDC federation. GitHub Actions, GitLab CI/CD, and CircleCI issue OIDC tokens natively, and Jenkins does through the OpenID Connect Provider plugin; each cloud exchanges the token for short-lived credentials, so no cloud keys are stored as CI secrets.
How do you enforce pipeline standards without a review bottleneck?
Put enforcement inside the template. Run actionlint, OPA or Conftest policies, and scanners on every pipeline, and use repository rulesets to require a passing pipeline before merge. The guild reviews only opt-outs.
How does Control Plane fit into a standard deployment pipeline?
It becomes the shared deploy target. The template builds and pushes the image, then runs cpln apply with the ready flag against the team’s GVC, authenticated by a service account whose policy covers only that team’s workloads. The CI system, runners, and tests stay with the teams.
What metrics show that standardized pipelines are working?
The four DORA delivery metrics plus pipeline duration, compared before and after adoption. Add runner use and cost per team for capacity planning.
Run every team’s workloads on one deploy target. Talk to the Control Plane team or sign up free.
Originally published on the Control Plane blog.
