▶️ Podcast Guide:

▶️ Video Guide:

Note: This video and podcast was generated using AI, adapting the original content and technical insights created by the author of the blog post.

What CI/CD means in Platform Engineering

Continuous integration and continuous delivery (CI/CD) are not new concepts in platform engineering. It basically means to build on every commit, run your tests, and deploy if they pass. But in a platform engineering context, CI/CD means something more specific: it is a centrally owned, standardized pipeline that product teams use rather than build one themselves. The platform team is not just providing a CI/CD tool; they are providing a fully tested, pre- configured system that handles the concerns we mentioned before that most teams shouldn’t have to think about: secrets management, container image signing, vulnerability scanning, deployment approval gates, rollback mechanisms, and observability hooks. All the developer needs to do is write the application code, and the platform handles how that code gets built, tested, and shipped. This differentiation matters because when CI/CD is just a tool that teams use independently, you end up with inconsistency: different security postures, different testing standards, different deployment patterns. When it’s a platform capability, consistency is the default.

The Golden Path concept

Platform teams talk about the “golden path”, which is just the recommended route for shipping software in your organization. The golden path for CI/CD is the pipeline template that encodes all the right practices by default and that the platform team builds and maintains. Although the golden path should be so easy to use and so clearly better than rolling your own, teams can diverge when they have a genuine reason to do so. It should handle the 80% case out of the box, and be extensible enough for the remaining 20%. In practice, the golden path for CI/CD might look like a set of reusable GitHub Actions workflows stored in a central repository, a shared Tekton pipeline catalog, or a set of ArgoCD ApplicationSet templates. The main principle, as we mentioned before, is the same: build it once, share it widely, improve it centrally.

What the Pipeline looks like

A CI/CD pipeline has a few distinct stages, each with a clear owner and purpose. The platform team is in charge of defining the structure; then, product teams fill in the application-specific details. Here is a realistic example using GitHub Actions with a reusable workflow pattern:

name: CI/CD Pipeline 
on: 
push: 
branches: [main, develop]
 pull_request:
 branches: [main]

 jobs:
 build-and-test:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4 
- name: Set up Python
 uses: actions/setup-python@v5
 with: 
python-version: "3.12"

 - name: Install dependencies
 run: pip install -r requirements.txt
 - name: Run tests 
run: pytest --cov=src tests/ 
- name: Run SAST scan
 uses: ./.github/actions/security-scan

 build-image:
 needs: build-and-test 
runs-on: ubuntu-latest 
steps: 
- uses: actions/checkout@v4
 - name: Build and push image
 uses: ./.github/actions/build-push
 with: 
registry: ${{ vars.REGISTRY_URL }} 
image: ${{ github.repository }} 

deploy-staging: 
needs: build-image 
uses: platform-org/workflows/.github/workflows/deploy.yml@main
 with: 
environment: staging
 image_tag: ${{ github.sha }}
 secrets: inherit

Notice the last step: deploy-staging calls a reusable workflow stored in platform-org/workflows. This is the key pattern. The deployment logic lives in the platform repository. And product teams can reference it by path and version. When the platform team updates the deployment workflow, every service that uses it picks up the change. Everything is propagated centrally: security patches, new approval gates, updated rollback logic (without needing to ask every team to update their pipelines manually).

Platform ownership matters

There are real, concrete benefits to owning CI/CD at the platform level rather than leaving it to individual teams:

• Security by default. When a SAST scanner or dependency audit runs in every pipeline by default, you don’t have to negotiate with teams about whether they should run it. It just runs. The same applies to secrets detection, container image scanning, and compliance checks. Security becomes structural rather than optional.
• Consistency. Every service goes through the same build, test, and deploy steps. Incidents are easier to debug because you know the deployment process is consistent. Onboarding new engineers is faster because the pipeline works the same way everywhere.
• Speed. Teams don’t spend time building pipelines. They spend time building features. A developer who joins a new team can open a pull request and have it deploy to staging in minutes, without understanding the underlying pipeline infrastructure.
• Visibility. When all pipelines use the same structure, you can build meaningful dashboards across the organization: deployment frequency, lead time, failure rate, mean time to recovery. These metrics are hard to collect when every team has a different pipeline shape. Platform-owned CI/CD makes DORA metrics tractable.

Challenges

There are also real challenges that any platform team will run into. Adoption is the first one. If the golden path doesn’t cover a team’s use case, they will build their own pipeline. And once a team has its own pipeline, migrating it onto the platform path is more complex. Platform teams have to invest time and resources in understanding what product teams actually need, and build for those needs rather than the needs they imagine teams have.

Maintenance is the second. A shared pipeline that twenty teams depend on is a critical piece of infrastructure. Breaking changes need to be communicated, versioned carefully, and rolled out with care. The platform team needs to treat the pipeline templates as a product: with versioned releases, a changelog, and a migration path for breaking changes. If teams get burned by a surprise pipeline change, they will stop trusting the platform.

Abstraction is the third. Hiding complexity is the whole point, but hiding it too aggressively makes debugging hard. When a pipeline fails, developers need to be able to understand why. If the pipeline is a black box that teams only interact with through a thin interface, failures become mysterious and frustrating. Good platform CI/CD design exposes enough of the internals that teams can diagnose problems without needing to become pipeline experts.

Conclusion

CI/CD is not a problem that each team should solve independently. When every team builds its own pipeline, you get inconsistency, fragile security practices, and engineering time wasted on infrastructure instead of product. Platform engineering solves this by treating CI/CD as a shared, centrally owned capability: a golden path that encodes the right practices by default and improves continuously.

Ideally, the platform team builds the pipeline once, governs it carefully, and makes it easy for product teams to adopt. It’s a win-win, developers get speed and simplicity while the organization gets consistency, visibility, and a security posture that doesn’t depend on every individual team making the right choices. Similar to IaC, platform-owned CI/CD is infrastructure treated as a first-class engineering concern.