One of the more hotly-debated developer topics online is when to deploy code. In a perfect world it shouldn't really matter, and we should be able to deploy frequently and often. But we don't live in a perfect world and it's important that we test everything we ship to our customers.
Another important concept is a consideration of when your users will be putting the most load on your software and planning accordingly. Of course, sometimes you have external pressures that dictate when software deploys need to happen.
One company I worked for had a long track record of waiting until the last second every single week to deploy software update, meaning 4pm or 5pm on Friday afternoon when most people want to be on their way home.
Of course, the pipelines in this project often didn't work right and often took a couple hours and/or required human intervention. It was so bad that we often tag-teamed the deploy where one person would drive home then hop online to monitor the deploy while the next person drove home.
The worst part of all of this wasn't even the deploy, but the fact that 60-80% of the traffic on our systems took place over the weekend and that we had minimal QA meant that bugs were almost always discovered over the weekend by the users.
After months and months of this, with a large number of our holidays and weekends getting taken over by emergency bug fixes, developers started dropping like flies.
Not going to lie, I was one of the people who burned out and left because of this deploy-on-Friday environment. To this day I avoid deploying on Friday, even though it's not a big deal on most of my projects.
