The problem is not that you shipped on Friday. The problem is that you have no way of knowing if shipping will break it. Most software is massively undermodeled and undertested.
Models (1) and tests (2) are two sides of software success: 1) do I understand this software so well that I can accurately predict the impact of a change in the system's behaviour 2) can I delonstrate confidence in its behaviour by repeatedly testing lots of scenarios
The irony is that both automated testing and modelling are crazy cheap compared to the perpetual burden and risk of undertested and undermodeled business-critical systems.
Getting started with both, in an existing system, is expensive and painful. But writing tests and doing modelling reinforces themselves and each other, and create a positive feedback loop of speed and quality improvement.
Teams that deploy succesfully on Fridays aren't just 25% faster than those who only deploy 4 days. They are 10s or 100s times faster, because they're so confident in every change, they have such predictable quality, that the time of the deploy doesn't even register as significant
These teams exist, it's achievable for yours as well, but it requires a change in habits and culture. And few people have seen such environments, so they don't believe it's possible.
To everyone who responded with "1-click rollbacks are great too": Yes, but rollbacks are hacks. They're necessary, but they're a blunt knife. If you don't fully understand the impact of change, you also don't understand the impact of a rollback.
A rollback returns your code and db to the previous state, but the side effect (the impacts on users, the emails that were sent, the api's called, the money transferred), all of that can't be rolled back. And on top of that, worst case, you've just rolled back the records of it.
If every rollback is well tested and the impacts are modelled, only then it is a truly safe and excellent tool to deploy more confidently — but if you have all that, rollbacks will be mostly unnecessary :-)
If we don't know understand your code well enough to write tests for it, how do we understand it well enough to build the right monitoring for it?
