Do we need Istio to do this?

No, but you need something that can split traffic deterministically. Istio is common, but NGINX Ingress with Argo Rollouts or Linkerd ServiceProfiles also works. Pick the one your team can operate at 2 a.m.

What about monorepos vs many repos?

Either works. The key is a single GitOps repo for desired state per environment. Use path conventions and ApplicationSets to scale. Keep release metadata consistent across services.

Can we do this without Kubernetes?

Yes, on ECS or Nomad with progressive delivery via Flagger or custom gateways. The principles—GitOps, canary gating with SLIs, feature flags, and fast rollback—still apply.

How do we keep checklists from rotting?

Treat them like code: PR reviews, owners, and link them in the pipeline so they have to pass to ship. Review them in postmortems; retire steps that provide no signal.

Release-engineering · Oct 9, 2025 · 10 minute read

The Multi‑Service Release Train That Stops Crashing: Automation That Cuts CFR, Lead Time, and MTTR

What actually works when you have 30+ services, a live database, and a CFO watching cloud spend in real time.

Riley Shaw

Partner, Release Engineering at GitPlumbers

20 years building and fixing delivery systems at Shopify, Netflix, and two unicorns you’ve definitely used. I lead Release Engineering at GitPlumbers and turn scary deploys into non-events.

You don’t need a bigger CAB; you need automation that assumes things will fail and makes failure cheap.

Back to all posts

The Multi‑Service Release Train That Stops Crashing: Automation That Cuts CFR, Lead Time, and MTTR

Key takeaways

Implementation checklist