Designing a CI/CD pipeline developers will not route around
A pipeline succeeds when it is fast enough to trust and strict enough to matter. Getting that balance wrong is why teams disable checks.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Platforms reduce duplicated infrastructure decisions across teams.
- Golden paths must be optional or they become workarounds.
- Treat the platform as a product with users and a roadmap.
- Start with the single most painful repeated task.
The problem it solves
As an organisation grows, every team solves the same problems independently: how to provision a service, wire up logging, get a database, deploy safely. The results diverge and the collective maintenance cost grows.
A platform provides a supported path through those decisions so teams can focus on their product rather than on infrastructure archaeology.
Golden paths, not golden cages
A golden path is an opinionated, well-supported route that covers the common case: a template that produces a service with logging, metrics, a pipeline, and sensible defaults already wired in.
It must remain optional. Teams with genuinely different requirements need a documented way to deviate, or they will deviate anyway and hide it.
Treat the platform as a product
- It has users — talk to them and measure their experience.
- It needs documentation people can follow without asking.
- It needs a roadmap and someone accountable for it.
- Adoption is voluntary and therefore an honest measure of quality.
Platforms that are mandated rather than adopted tend to be worked around, and the workarounds become the real platform.
Start small
The failure mode is a two-year programme to build a comprehensive platform nobody asked for. Start with the single most painful repeated task — usually provisioning a new service or getting an environment — and make that excellent.
Expand based on what teams actually ask for next, which is rarely what the platform team predicted.
Measuring whether the platform helps
Platform teams can be busy and ineffective, and the difference is measurable. Track time from a new service being requested to it running in production, and how much of a product team's time goes on infrastructure concerns.
Survey the developers using it, and read the support requests. Recurring questions indicate documentation gaps or genuinely confusing design, and they are the clearest available roadmap.
If adoption is voluntary and rising, the platform is working. If it needs mandating, something about the ergonomics is wrong and no amount of policy will fix it.
Frequently asked questions
The economics start working somewhere around several delivery teams. Below that, shared templates and good documentation achieve much of the benefit without a dedicated team.
It is a specific approach within it: rather than every team operating everything, a platform team provides paved routes so product teams retain ownership without rebuilding the same foundations.
Time from idea to running service, adoption rate of the golden path, and how much time product teams spend on infrastructure work. All three are observable.
