DevOps & CI/CD
Shipping should be boring
If a release is an event — a window, a checklist, someone staying late — the deployment process has become a constraint on the business rather than a detail of it.
In short
CI/CD is the practice of making a change reach production automatically, safely and often enough to be unremarkable. Continuous integration means every change is built and tested on merge; continuous delivery means a passing build can be released without manual assembly. The measure that matters is not deployment frequency for its own sake — it is how long it takes to ship a one-line fix, and whether anyone is nervous when it happens.
When it applies
Signals this is the work
If more than one of these is true today, the problem is usually further along than it looks from the outside.
Releases need a window
Deployment is scheduled out of hours because it is risky, which makes it rarer, which makes it riskier.
Someone deploys by hand
Steps are performed in order from a document, and the document is slightly out of date.
Rollback is theoretical
There is a plan. It has never been executed under pressure.
"Works on staging"
Environments differ in ways nobody has catalogued, so staging proves less than it appears to.
Small fixes wait for the batch
A trivial change sits for a week because shipping is expensive, and ships with nine other changes that complicate diagnosis.
How we do it
The sequence
- 01
Make the build reproducible
Same inputs, same artifact, no machine-specific steps. Everything else depends on this.
- 02
Automate the tests that matter
Enough coverage to trust a green build. Not a coverage target — the specific tests that would have caught the last three incidents.
- 03
One pipeline to every environment
The same process promotes to staging and production. Divergent paths are how staging stops predicting anything.
- 04
Make rollback routine
Tested, fast, and rehearsed. A rollback nobody has performed is a hope.
- 05
Infrastructure as code
Environments described in version control, so parity is verifiable and rebuilding is possible.
- 06
Measure lead time
How long from merge to production. It is the number that tells you whether any of this is working.
What we will not do
The refusals
- Introduce Kubernetes to solve a deployment problem that is about process.
- Chase a coverage percentage instead of testing what actually breaks.
- Automate a deployment that has no rollback path.
- Build a pipeline more complex than the team that has to maintain it.
Questions
Before you ask
Tell us what isn't working.
One process, one system, one decision you are stuck on. We will come back with how we would approach it, what it would take, and whether it needs building at all.