# Your Deploy Button Should Be a Git Commit, Not a Click

> **TL;DR:** Of the six practices that define a modern pipeline, two do the specific work of making a bad deploy *reversible* instead of just *preventable*: GitOps (Git as the single source of truth for what's running in production) and progressive delivery (canary releases and feature flags that limit a release's blast radius). Together they're why recovery time, not just deploy frequency, is a number worth optimizing. A Dubai proptech company's recovery time went from 5 hours to 12 minutes once both were in place.

Most CI/CD writeups lead with deployment frequency, because "we ship more often" is the easy, visible win. The practice that actually determines whether shipping more often is *safe* is further down the list: can a bad release be undone in minutes by someone who didn't write it, or does undoing it require a person who remembers the manual steps backward? GitOps and progressive delivery are the two practices that answer that question well.

## GitOps: Git as the only path to production

GitOps makes a Git repository the single source of truth for what's actually running. Instead of pushing changes by hand, you describe the desired state in the repo, and a tool (Argo CD, for Kubernetes) continuously reconciles the live environment to match it. The mechanical consequence: every production change is a commit. That buys you three things for free,

*   **Full history.** `git log` is your deploy history, not a separate changelog someone has to maintain.
    
*   **Review before it ships.** A PR against the desired-state repo gets reviewed the same way application code does.
    
*   **Rollback is a revert.** Undoing a bad release is `git revert` plus reconciliation, not a person remembering what the previous config looked like.
    

The practical effect for incident response: the person on call doesn't need tribal knowledge of "how we used to deploy this service", the answer is always "what did the repo look like an hour ago."

## Progressive delivery: shrinking the blast radius before rollback is even needed

GitOps makes undoing a release fast. Progressive delivery (canary releases, feature flags) reduces how often you need to. A canary release sends the new version to a small slice of users first, widens if metrics hold, and stops if they don't, reaching only a few users before a problem would reach everyone. Feature flags add the same control at the feature level: a risky feature switches off without a redeploy at all, because the flag check happens at runtime.

Combined, the two practices form a pipeline: GitOps controls *how* a change gets to production and how fast it can be undone; progressive delivery controls *how much* of production that change actually touches before you know it's safe.

## Where these sit among the full six

| # | Practice | What it delivers |
| --- | --- | --- |
| 1 | Automate the whole pipeline | Build, test, deploy on every change |
| 2 | Test automatically at every stage | Catches bugs before users do |
| 3 | Ship small with progressive delivery | Canary + feature flags lower blast radius |
| 4 | Build security into the pipeline | Scans every change (DevSecOps) |
| 5 | Deploy with GitOps | Git as the source of truth for what's live |
| 6 | Observe and roll back fast | Detects trouble early, reverts in seconds |

Practices 1, 2, and 4 make a release *less likely to be bad*. Practices 3, 5, and 6 make a bad release *cheap to undo*, and it's that second group that moves recovery time, specifically, which is a different DORA metric than deployment frequency and arguably the one that matters more when something actually goes wrong.

## Case study: 5 hours to 12 minutes

A Dubai proptech company's releases had become a monthly ordeal, each one bundled weeks of changes, took a full evening of manual work, and about one in four caused a production problem. Five-month rebuild:

| Problem | What was built | Outcome |
| --- | --- | --- |
| Manual monthly releases | Fully automated build/test/deploy pipeline | Deploys: monthly → daily |
| Slow path to production | Trunk-based workflow, automated tests | Lead time: 8 days → 90 minutes |
| Frequent broken releases | Canary releases + automated rollback | Change-failure rate: 25% → 5% |
| Slow incident recovery | Monitoring tied to the pipeline, GitOps rollback | **Recovery time: 5 hours → 12 minutes** |

The recovery-time row is the one this piece is about: GitOps meant a bad release was a revert instead of a manual unwind, and canary releases meant most bad releases were caught while they still only affected a small slice of traffic. The other three rows improved too, but they'd have mattered a lot less without a fast way out when something slipped through anyway.

## FAQ

**Is GitOps only useful for Kubernetes?** Argo CD specifically targets Kubernetes, but the underlying pattern (declarative desired state in Git, reconciled continuously) applies more broadly, the Kubernetes tooling is just the most mature implementation.

**Do we need both GitOps and progressive delivery, or does one cover it?** They solve different halves of the same problem. GitOps makes a bad release cheap to *undo*. Progressive delivery makes a bad release affect *fewer people* before you notice. You want both, GitOps without progressive delivery still ships a bug to 100% of users before the revert lands.

**What's the single highest-leverage practice to add first if we have none of these?** Automated tests in the pipeline (practice 2), it's the prerequisite that makes trunk-based, frequent deploys safe enough to attempt GitOps and progressive delivery on top of.

* * *

*This is a condensed take on* [*the full write-up*](https://sherdilcloud.com/ci-cd-pipelines-explained-building-faster-safer-and-smarter-applications/) *(with the complete six-practice breakdown and the four DORA metrics in depth). For the hands-on pipeline build, see* [*CI/CD pipeline from scratch*](https://sherdilcloud.com/build-cicd-pipeline-from-scratch/)*; for the cloud foundation underneath it,* [*DevOps in the cloud*](https://sherdilcloud.com/devops-in-the-cloud-innovate-faster/)*.*

**About the author:** Muhammad Usman is Head of DevOps at Sherdil Cloud, AWS DevOps Engineer Professional, Certified Kubernetes Administrator (CKA), and Alibaba Cloud Certified, building cloud and DevOps infrastructure for enterprises across Pakistan, the UAE, and the United States since 2014.