Do we need a monorepo to do a release manifest?

No. The manifest works with polyrepos too. The key is that the manifest pins immutable artifacts (image digests, chart versions), not branches. Your build system can publish artifacts from many repos; the release cut step assembles them into one promoted document.

What if different services have different rollout needs?

That’s normal. Put rollout strategy per service in the manifest (canary for tier-1, batch for tier-2, rolling for internal). Standardize the interface (health checks, gates), not the implementation.

How do we handle database migrations safely?

Default to expand/contract. Automate checks that prod releases only include backward-compatible changes unless explicitly approved. If rollback isn’t possible, document the forward-fix plan and make it part of the release gates.

How do we measure change failure rate reliably?

Pick an operational definition and automate it: deployments that trigger rollback, hotfix PRs, or SLO burn alerts within a time window (e.g., 24 hours). The exact definition matters less than consistency and tying it to release metadata.

Release-engineering · Dec 25, 2025 · 8 minute read

The 17-Service Release That Taught Us to Stop “Coordinating” and Start Automating

Multi-service releases don’t fail because engineers are dumb. They fail because the system is built on tribal knowledge, Slack pings, and “please don’t merge right now.” Here’s the automation pattern that actually moves your change failure rate, lead time, and recovery time.

Back to all posts

The 17-Service Release That Taught Us to Stop “Coordinating” and Start Automating

Key takeaways

Implementation checklist