Problem
Delivery behavior had accumulated inside individual projects. Similar services used different pipeline stages, environment branches, Helm invocations, and validation rules. Changes that should have been routine required project-specific knowledge, and reviewing a release meant rediscovering which assumptions were hidden in that repository.
The platform targets were not identical. Kubernetes and OpenShift shared most application delivery concerns, but OpenShift security constraints, routes, image-user behavior, and permissions could not be treated as cosmetic differences.
Constraints
- Existing services had to keep shipping while the shared path was introduced.
- Environment-specific values and credentials could not leak into reusable templates.
- Security checks needed to run inside delivery, not as an unrelated reporting exercise.
- Teams needed useful failure output and a documented escape path for exceptional releases.
- The design had to work in restricted enterprise environments rather than assume unrestricted registry or network access.
Approach
I separated the contract into layers: reusable pipeline behavior, service-owned inputs, environment configuration, and platform-specific deployment logic. GitLab templates defined stable stages and validation. Services declared the small set of inputs they owned. Helm handled the shared application model, while targeted values and templates expressed actual platform differences.
The release path made image identity explicit and promoted the same artifact instead of rebuilding per environment. Validation included configuration rendering, security and vulnerability checks, and deployment readiness. Operational metadata—service, environment, release identity, and deployment status—was kept consistent enough to connect pipeline evidence with runtime monitoring and logs.
Adoption was incremental. A representative service proved the interface first. The reusable path was then adjusted from real edge cases before more repositories moved to it. Exceptions remained visible; they did not become silent branches inside a supposedly universal template.
Result
Delivery stopped depending as heavily on one-off project logic. Pipeline behavior became easier to review and update centrally, while service repositories retained ownership of application-specific configuration. Kubernetes and OpenShift differences were handled intentionally instead of through copy-pasted pipelines.
The larger gain was operational: a failed release produced more consistent evidence, and engineers could reason about the path without first learning a custom deployment system for every service.
What mattered
- A shared template needs a small, versioned input contract. A giant variable surface simply relocates complexity.
- Artifact promotion is safer than per-environment rebuilds.
- OpenShift constraints belong in design and test stages, not last-minute exceptions.
- Centralization is only useful when failure output remains local and understandable.
- Migration should prove conventions with real services before enforcing them broadly.
Related work: CI/CD automation and Kubernetes and OpenShift engineering.