Deployment frequency
How often you release to production.
Tells you whether releases are small and routine or big and risky.
DevOps & CI/CDRelease engineering
Releases your team doesn’t dread
If shipping a small fix means booking an evening, finding the one person who knows the steps and hoping staging told the truth, your release process is costing more than it looks. We fix that, usually without replacing the tools you already pay for.
- MergeReviewed pull request lands on mainpassed
- BuildOne package, built the same way every timepassed
- TestThe tests that would have caught past incidentspassed
- StagingDeployed by the same pipeline as productionpassed
- ProductionA small change, released in working hourspassed
Rollback to the previous release in minutes, rehearsed on purpose
What CI/CD actually means
CI/CD means every change is built and tested automatically when it is merged, and any build that passes can go to production without someone assembling it by hand. DevOps is the wider habit around that: environments defined in code, releases small enough to reason about, and a rollback that has been used before. We judge the result with two plain questions. How long does a one-line fix take to reach customers? And does anyone get nervous when it goes out?
You probably need this if…
- Deploys happen after hours. Daytime releases went wrong once, so they moved to evenings. Fewer releases means bigger ones, and bigger ones break more often.
- The steps live in a wiki page. Someone follows it line by line. Step seven changed last spring and the page was never updated.
- Nobody has actually rolled back. There is a rollback plan. It has never been run with customers waiting.
- Staging passed, production did not. The two environments drifted apart a while ago, and nobody has a list of the differences.
- Small fixes wait for the next release. A typo fix sits for a week, then ships with nine other changes. When something breaks, nobody can say which change caused it.
Where do we stand?
Five stages of a release process
Pick the one that sounds most like your team today. You’ll see the next thing worth doing. Nothing is sent anywhere.
Your next step
Choose a stage above.
Most teams that contact us are at stage two or three: automated builds, manual releases.
Talk it through with usHow we work
Six jobs, in this order
The order matters. Automating a build that isn’t repeatable just gets you unreliable releases faster.
- 01
Make the build repeatable
Same code in, same package out, whoever runs it and on whatever machine. We start here because every later step depends on it.
- 02
Test what has actually broken
We read your last few incidents and write the tests that would have caught them. A coverage target can come later, if it is useful at all.
- 03
One route to every environment
Staging and production are deployed by the same pipeline with the same steps. Once the routes differ, staging stops telling you anything.
- 04
Rehearse the rollback
We roll back on purpose, in working hours, until it takes minutes and nobody has to look up how.
- 05
Put the infrastructure in version control
Servers, networks and settings are described with Terraform or a similar tool, so you can see what changed, compare environments and rebuild one when you need to.
- 06
Track lead time from day one
We record how long a merged change takes to reach production before we start and as we go. If the number is not coming down, you will hear it from us first.
Proof, not promises
Four numbers we record before touching anything
They come from Google’s DORA research and are the most widely used way to judge how well a team ships software. We take your baseline in the first week, so you can see whether the work made a difference.
Lead time for changes
Time from a merged change to running in production.
The clearest single sign of how much friction sits in the process.
Change failure rate
Share of releases that need a hotfix or a rollback.
Keeps speed honest. Shipping faster only counts if this holds steady.
Time to restore
How long it takes to recover when a release goes wrong.
Shows whether rollback is a real option or a plan on paper.
The hard parts
Where most pipelines quietly give up
Building and testing code is the easy bit. These two are what usually keep releases manual.
Database changes
Change the schema without trapping your data
A release that renames a column can’t simply be rolled back, because the old code no longer understands the data. We split risky changes into safe steps.
- ExpandAdd the new column alongside the old one. Both versions of the app keep working.
- MigrateMove the data across in the background and switch the app over.
- ContractRemove the old column in a later release, once nothing uses it.
Secrets & configuration
Keep keys out of code, and settings out of people’s heads
Plenty of manual releases exist because a password or setting has to be typed in on the day. We move those somewhere the pipeline can use safely.
- Passwords in the repository, pipeline files or a shared spreadsheet
- Production values copied by hand into each server
- A secrets manager in your own cloud account, read at deploy time
- Separate values per environment, with access you can revoke
Tooling
We work in the tools you already have
Switching CI provider rarely fixes a release problem. If yours does the job, we keep it.
CI/CD
- GitHub Actions
- GitLab CI
- Bitbucket Pipelines
- Azure DevOps
- Jenkins
Containers & hosting
- Docker
- Managed app platforms
- ECS / Cloud Run
- Kubernetes, where it earns its keep
Infrastructure as code
- Terraform
- OpenTofu
- CloudFormation
- Bicep
Clouds
- AWS
- Microsoft Azure
- Google Cloud
- DigitalOcean
Ground rules
Shortcuts we won’t take
Each one makes a pipeline look finished sooner and fail later.
We will notDevOps & CI/CD
- 01
Switch off a failing test just to get a green build.
- 02
Keep production passwords or API keys in pipeline files or the repository.
- 03
Automate a deployment that has no way back.
- 04
Leave you with a pipeline that only we know how to maintain.
Questions
What teams usually ask us
If yours isn’t here, send it over. An engineer will answer, not a salesperson.
How long does it take to set up?
Getting a basic pipeline running on a well-organised application is usually quick. The longer work is around it: tests you can trust, making staging match production, and sorting out configuration and secrets, which is where most teams get stuck. After a short look at your setup we can tell you which of those applies to you.
Do we need Kubernetes to do this properly?
Probably not. Most teams we see ship just as reliably on a managed app platform or plain container hosting, with far less to look after. If your traffic or team size genuinely calls for it, we will say so and explain what it takes to run.
How do you handle database changes?
Carefully, because this is where deployment automation usually gets hard. Migrations are written so the previous version of the app still works with the new schema, which means a rollback does not strand data. They are versioned, run by the pipeline and tried against a realistic copy of the data first.
We already have a pipeline. Do we start again?
Almost never. Most pipelines we inherit handle the easy part and stop short: no rollback, a staging environment that has drifted, or no test for the thing that keeps breaking. Filling those gaps costs far less than a rebuild.
Which CI tools do you work with?
GitHub Actions, GitLab CI, Bitbucket Pipelines, Azure DevOps and Jenkins are the ones we meet most often. We work in whichever one you already use.
Send us your release checklist.
Paste in the steps your team follows to deploy, or tell us about the last release that went wrong. We’ll reply within one working day with where we would start.