deveshThe problem
Thirty repositories, thirty slightly different build scripts, one shared Jenkins box that everyone feared restarting. Deploys happened about three times a week, each one a coordinated event with a rollback plan written in hope. Engineers spent more time fighting the pipeline than shipping.
The approach
Standardise, don't multiply. I built a small library of reusable GitHub Actions workflows — build, test, containerise, publish, deploy — that every repository calls with a few lines of configuration. One fix in the shared workflow propagates to all thirty repos; no more copy-pasted YAML drifting apart.
Containers as the only artifact. Every service builds to a Docker image with a content-addressed tag. What was tested is byte-for-byte what deploys — no "works on the build box" surprises.
Helm for releases. Each service ships a Helm chart with sane defaults and per-environment values. Deploys became helm upgrade operations with built-in history and one-command rollback.
Trunk-based flow with safety rails. Short-lived branches, required status checks, automated tests as the gate, and staging deploys on every merge. Production deploys became a routine promotion, not an event.
The outcome
- Deploy frequency went from 3/week to 20+/day across the organisation.
- Lead time from merge to production dropped from days to under thirty minutes.
- Rollbacks went from an incident to a command.
- The shared-workflow library meant new services got a production-grade
pipeline on day one — onboarding a repo takes minutes, not a sprint.