The thing missing from this setup for me is a ramp up of changes on release, and automated rollback based on service metrics/KPIs. Don't release to the world.

The thing missing from this setup for me is a ramp up of changes on release, and automated rollback based on service metrics/KPIs. Don't release to the world. Release to 1%, then 5% then 20%... and so on. And if the load time starts going up, or the # errors start going up, or numerous other things - last release gets rolled back and alarms ring. That way I don't break the world - I break a much smaller N% of the world that demonstrates the problem - which then promptly gets rolled back by the friendly neighbourhood release bots. I write sucky code - so I write tests to help drive my design and catch errors. But tests are code too - and I write sucky code - so I write release processes[1] they help save me when I write sucky test code. If you do continual delivery you need that second layer of metric-driven tracking of release quality or writing sucky test code will catch you out at some point ;-) [1] and yes - the release ramp up / roll back code is potentially sucky code also - but it's just one bit that does one thing so gets tested a lot more than all the new sucky code I write ;-)