How to cut deployment lead time from days to minutes

If it takes your team days to get a change into production, the problem is rarely the code — it's the path the code travels. Every hand-off, queue, and manual check on that path adds waiting time, and waiting time is most of lead time. Shortening the path is one of the highest-leverage investments an engineering organization can make: smaller changes reach users sooner, fail less often, and are easier to fix when they do.

Here is the order in which we usually tackle it.

Measure first

You can't improve what you don't measure. Track the four DORA metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service. Lead time and change failure rate matter most here because they keep each other honest — going faster only counts if failures don't rise with it.

A rough baseline is enough. Take the last month of merged pull requests and record, for each one, when the first commit was made, when it was merged, and when it reached production. The gaps show where changes wait:

• Long first-commit-to-merge times point at review queues or oversized changes.
• Long merge-to-production times point at release trains, manual approvals, or slow pipelines.
• Frequent reverts and hotfixes point at missing tests or risky deploys.

Make the pipeline the only path

Every change should reach production the same way: through an automated pipeline with tests, scanning, and deployment built in. Manual steps — someone running a script, clicking through a console, or copying artifacts between environments — are where time and consistency go to die.

Build the artifact once and promote that same artifact through each environment; rebuilding per environment means the thing you tested isn't the thing you ship. Keep environment differences in configuration, not in code branches. And keep the pipeline fast. If it takes 40 minutes, engineers batch changes to avoid waiting for it, which brings back the big releases you are trying to eliminate. Dependency caching, parallel test runs, and moving slow end-to-end suites out of the merge gate usually pay off quickly.

When many teams run many services, give them a golden path: shared pipeline templates with testing, scanning, and deployment already included, so a new service gets a production-ready pipeline in hours. That is how we cut lead time from days to under an hour for a 60-engineer SaaS team.

Shrink the batch size

Small, frequent changes are safer and faster to review than big-bang releases. A 50-line pull request gets a careful review in minutes; a 2,000-line one waits for days and then gets a skim.

• Merge to trunk at least daily and keep branches short-lived.
• Put unfinished work behind feature flags, so merging and releasing become separate decisions.
• Break large changes into a sequence of safe steps: add the new path, migrate callers, remove the old path.
• Make database migrations backward compatible, so code and schema can deploy independently.

Automate the safety net

Progressive delivery — canaries and automated rollbacks — means a bad deploy is a non-event, not an incident. A new version first takes a small share of traffic; if error rate or latency degrade, the rollout stops and reverts on its own. We explain why we default to Argo Rollouts for this on Kubernetes.

Rollback has to be fast and boring. If restoring the previous version takes a meeting and a manual procedure, teams slow down to avoid ever needing it. When rollback is instant and automatic, teams stop fearing deployment and start doing it constantly.

Remove approvals that don't add safety

Change advisory boards and manual sign-offs feel safe, but they mostly add waiting time. An approver looking at a large batch of changes they didn't write rarely catches what tests and code review missed. Peer review on every pull request, automated checks in the pipeline, and an audit trail of who deployed what usually give better control — and they satisfy auditors too, SOC 2 included.

What good looks like

Teams that get this right ship many times a day, with lead times measured in minutes or hours, and a change failure rate that falls rather than rises as they speed up. Getting there is rarely one project. It is a series of small fixes to the path, each guided by the measurements you took at the start.

This is the core of our DevOps and platform engineering work. If your lead time is measured in days and you want to know where the time goes, get in touch.