“No deploy Fridays” can become a bit of a joke for some teams. Because, if we don’t laugh, we’ll cry. Behind this dark humour is a real fear of something going wrong, a fear of having to work late to fix an incident, or worse, a fear of being blamed for it.

A “code freeze” before a big event is another one. It’s a sign that we’re not confident enough to roll out new code without breaking something.

Agile development is about releasing early, getting feedback from the customer, and responding to change. A code freeze nips that in the bud. No releases, no feedback, no agility. Releasing early minimises the time spent building the wrong thing.

In fact, assuming developers are still building features during the freeze, just not releasing them, we end up bundling a whole bunch of changes ready to release once the freeze is thawed. A release with more changes has higher chance of going wrong, which increases the fear. It’s a vicious cycle. Small and frequent deployments reduce the chance of deployments going wrong.

Confidence

• Automated testing
• Monitoring
• Rollbacks
• Canary roll-outs
• Release channels

Accepting Failure as Normal