60% More Releases

TL;DR

At Getir I owned the move to GitOps with ArgoCD and Flux across a ~200-engineer org. Deploys went from hours to about 5 minutes, releases climbed roughly 60%, and Git became the single source of truth for what ran in production.

Context

Getir was scaling faster than its deployment process. Shipping a change meant hours of manual steps — kubectl runs, SSH sessions, tribal knowledge that lived in three people's heads and nowhere else. Every team did it slightly differently, so "how do we deploy this service" had a different answer depending on who you asked.

Problem

The real cost wasn't the wasted hours. It was the fear. Rollbacks were painful and uncertain, so engineers batched up changes and held their breath on release day. The less often they deployed, the riskier each deploy became, and the more they wanted to avoid deploying. A classic doom loop. On top of that, nothing detected drift — production could quietly diverge from what anyone thought was running, and we'd only find out during an incident.

The Insight

GitOps turned out to be a culture migration wearing a tooling migration's clothes. My first instinct was a clean org-wide cutover — define the standard, announce the date, flip everyone over. I'm glad I didn't.

The blocker was never the hours; it was fear. Rollbacks had been painful and uncertain, so people batched changes and braced for release day. Once the safety net was automatic and visible — push a change, watch it sync, watch a bad one roll back on its own — deploying stopped feeling risky. Teams shipped more often not because we told them to, but because the cost of a mistake had dropped.

That reframed how I ran the rollout. Instead of mandating, I started with the teams that wanted in and let automatic rollback do the convincing — early adopters carried the story to the skeptics far more credibly than any rollout plan from me could.

What I Did

1. Mapped the real workflows. I sat with teams and documented how deploys actually happened, not how the runbooks said they did.
2. Picked tools for adoption, not aesthetics. ArgoCD for app teams, Flux + Terraform controller for infra.
3. Made Git the source of truth. Every config change went through version control, giving us an audit trail for free.
4. Started with willing teams. Early adopters proved the value and became the internal advocates that pulled the rest of the org along.

Key Decisions

The instinct from leadership was to standardize on one tool and mandate it. I pushed back. I'd evaluated the leading GitOps tools, and the honest answer was that no single one was best at both jobs. ArgoCD had the UI and the approachability that would win over application teams who didn't want to think about reconciliation loops. Flux fit our infrastructure layer far better because of how cleanly it slotted into our Terraform workflow.

So I made the call to run both — ArgoCD for apps, Flux for infra — and own the integration cost myself rather than force a worse fit on one side to keep the toolbox tidy. It was the less elegant choice on paper and the right one in practice. Adoption is a product problem, not a purity problem.

Results

Beyond the headline numbers: configuration stayed consistent across services, every change carried an audit trail, and drift that used to surface as a production incident now got caught and reconciled automatically. Most importantly, engineers deployed confidently because the rollback was no longer something they had to think about.

Lessons Learned

1. GitOps is a culture change first. The implementation was the easy part — shifting how teams felt about shipping took the most work.
2. Make the safety net visible. Release frequency followed trust, and trust followed seeing automatic rollback work with their own eyes.
3. Start with the willing. Volunteers prove value and become advocates; mandates create resistance.
4. Pick for adoption. Running ArgoCD and Flux together was less tidy and far more effective than forcing one tool to do both jobs badly.