.jpg)
There is an opinion in the IT community that Friday deployments are bad thing and should be avoided. There are plenty of reasonable, valid arguments and quite similar number of other ones which I find rather funny. They all form a clear message: don’t deploy to production on Friday, otherwise your world would end, depending on your sense of humor.
Credits for D.W. for inspiring me with the title and generally to write this post with making a slack notification of upcoming deployment:
Ready to waste your weekend?
The major argument against Friday deployments is the lack of people to fix a potential problem or - in best case - the weekend wasted on those fixes. This is an absolutely valid point. Many people plan their weekends in advance. On the other hand, let’s try to think about what would be worse from the company’s perspective which ultimately is also employee’s perspective, isn’t it?
Let’s consider two hypothetical situations, having something in common.
My team and myself develop software that is used in garages and car repair workshops mostly during weekdays (similarly to software developed for eg. governmental bodies and public institutions). It’s a popular scenario, isn’t it? Let’s assume our next deployment will introduce a serious bug that will take 2 days to fix.
- Situation A: we deploy on Tuesdays, because we agree with the opinion about Friday deployment being “risky”. What’s more we’ve heard Apple does deploy on Tuesdays.
- Situation B: we deploy on Fridays, because we don’t mind staying at the office during weekend aka we have no private life ;)
Situation A would result with our service being unavailable for the end users in the, usually, most critical part of the week: Wednesday and Thursday. Depending on many factors like the number of users, price of our service, and many other, the loss could be really massive. In the end it could be employees getting fired or - in the best case - no bonus.
Situation B would result with our service being unavailable on Saturday and Sunday where we hardly have any usage. We would need to pay extra for the whole team working hard on weekend and handle their dissatisfaction due to changed plans. Maybe not all of the team members could make it and it would take a part of Monday to fix it completely.
I let you decide which of these two looks better/worse for you. I’ve just tried to emphasize a very important fact being ignored when discussing the Friday deployments “problem” - that is the nature, the features, the specifics of the business that we are developing our services for. In my opinion this should be the very first point in all the considerations. When delivering a booking system for cafes or restaurants with the peak usage on Thursday, Friday and Saturday I would definitely try to avoid deploying on Thursday or Friday.
My bank’s policy
The subject itself sounds interesting to me so I’ve spent some time analyzing my bank’s policy on software updates, maintenance etc. What makes them different to my current project’s target users is the fact that they must be available always. ALWAYS.
Office hours - definitely, Weekends - oh yes. Nights? Usually too.
During the last 18 months they did all the deployments (at least those announced) on Sunday/Monday morning between 2 AM and 5 AM. So in my opinion the only thing they cared about is the least impact on their customers rather than people unavailable or “weekend wasted”.
It’s not just our bugs
Last but not least we should take external problems into account. Of course, they may happen, and we are not always able to control them - there are always data centers, 3rd party service providers and other things that may go wrong. And they will always happen, no matter when we deploy. Interestingly the arguments against Friday deployments usually mention only the bugs we create.
StackOverflow 2nd most popular answer for the question about deploying on Friday says:
You pretty much answered your own question. It's a short and sweet reason: if you ship on a Friday, and a bug makes it into production, there's generally no one around to fix it or talk to the customers until the following Monday. That's potentially several days of lost revenue in a worst-case scenario.
Bugs in production should be a minority, they should be exceptional. These days we have mature processes with Continuous Integration, all kinds of testing, from unit to end-to-end, code reviews, sandboxes, staging, pre-productions (or 5 different environments prior to production which have to be signed off first - that’s my case). One should be confident about the code quality going to production and still prepare for the worst - in advance - with a proper rollback procedure. Again, these days we have the right tools, ie. Continuous Integration Server, that makes it lots easier. With that in mind one may think about deployments only from the user perspective: how to minimize the risk of the service becoming unavailable. That’s why I am not against deploying on Friday if that helps me achieving this goal.
And now the answer for the two most intriguing questions you have in mind: 1) Yes, I do. I do have family and love spending weekends with them. 2) I don’t remember any single weekend wasted in the office on fixing broken production deployment. Have a nice Friday release!
There is an opinion in the IT community that Friday deployments are bad thing and should be avoided. There are plenty of reasonable, valid arguments and quite similar number of other ones which I find rather funny. 1Credits for D.W. for inspiring me with the title and generally to write this post with making a slack notification of upcoming deployment:
"Hell, yeah production on Friday"
