Substrate

#observability #technical-lead #process
On the issues with Friday deploy freezes
On the issues with Friday deploy freezes
Fear of deploys is the ultimate technical debt. ​ Deploys are the heartbeat of your company. ​ as pedestrian as the day of the week. ​ Deploy on every commit. Smaller, coherent changesets transform into debuggable, understandable deploys. ​ If you do not block merges on Fridays, and only block deploys, you are queueing up a bunch of changes to all get shipped days later, long after the engineers wrote the code and have forgotten half of the context. Any problems you encounter will be MUCH harder to debug on Monday in a muddled blob of changes than they would have been just shipping crisply, one at a time on Friday. Is it worth sacrificing your entire Monday? Monday-Tuesday? Monday-Tuesday-Wednesday? ​ have all happened after holiday code freezes. Every. Single. One. ​ The “safety” of nodeploy Friday is realized immediately, while the costs are felt later later. ​ Finally, I heard from a alarming number of people who admitted that Friday deploy bans were useless or counterproductive, but they supported them anyway as a purely symbolic gesture to show that they supported work/life balance. This makes me really sad. I’m … glad they want to support work/life balance, but surely we can come up with some other gestures that don’t work directly counter to their goals of life/work balance. That's it. Because if you make it a virtue signal, it will NEVER GET FIXED. Blocking Friday deploy is not a mark of moral virtue; it is a physical bash script patching over technical rot. And technical rot is bad because it HURTS PEOPLE. It is in your interest to fix it.
·charity.wtf·
On the issues with Friday deploy freezes