- Monday
- Tuesday
- Wednesday
- Thursday
- Friday
- Saturday
- Sunday
and the times:
- One O'Clock
- Two O'Clock
- ...
and obviously a bunch of holidays and unrelated business synchronizing events (black friday, sales deadlines, etc) that you also shouldn't deploy on.
However, if you really believe this, you should stop writing, managing or using software NOW! Unfortunately, you will deploy broken code, because:
"I’m sorry to say so but, sadly, it’s true that Bang-ups and Hang-ups can happen to you."And when you do deploy that broken code, it probably had nothing to do with when it was deployed. In fact no one probably would've noticed if you did just one thing...
- Dr. Seuss (Oh, the places you'll go!)
ROLLBACK!
Three rules:
- Code must always be able to be rolled back.
- Rollback must be a single command.
- The rules for rollback must be simple, easy-to-follow and aggressive. (ie. Customer call related to issue with release, exception related to a release, etc.)... then, just...
ROLLBACK!
Then, figure out what went wrong, how to prevent it from happening again... rinse and repeat... any day... any time.
Isn't our philosophy designed for roll forward?
ReplyDeletenah, we need to be able to rollback, turn features off, etc. you can only have a roll forward policy if you can guarantee that the fixes will take less time than the rollback and won't introduce new defects. since even you can't guarantee that... we need to be able to rollback.
ReplyDelete