> Sure, there are some high-priority bugs that are breaking the site that need to be fixed ASAP
This is why after making "deploy" a one-click operation, "roll back to the last deployed version" should also be a one-click operation.
Fixing things "ASAP" in a panic doesn't work at all well. First get to a known good state and then do a calm assessment of the right fix, taking as much or as little time as you need (and no need to work late).
I know that this doesn't work for all failures - If a server's drive fails, you still need a plan for how to repair - but it does for many common things.
This is also why having rules about when you can release new features or big changes is very valuable. Or at the very least training your team to stop and think about the timing before pressing the deploy button.
There are rarely cases when a new feature needs released Fri at 4pm or days before a holiday break.
Yep! Agreed! Usually the bugs I'm talking about are things we didn't catch until well after deployment where a hotfix makes more sense than rolling back. But you're right, if something goes wrong soon after deployment, we roll back immediately!
This is why after making "deploy" a one-click operation, "roll back to the last deployed version" should also be a one-click operation.
Fixing things "ASAP" in a panic doesn't work at all well. First get to a known good state and then do a calm assessment of the right fix, taking as much or as little time as you need (and no need to work late).
I know that this doesn't work for all failures - If a server's drive fails, you still need a plan for how to repair - but it does for many common things.