Why not to deploy on a Friday?

Question

Joel mentioned in StackOverflow podcast #24 that it's FogCreek company policy to not ship software on Fridays. However, he didn't elaborate as to why.

I agree. At my employer, we deploy on Thursday nights. So we have Friday to cleanup any bugs that missed Quality Assurance (QA).

However, my manager suggested that we deploy on Friday nights in the event that QA doesn't have enough time to test the software before a release. I say, What about people's weekend plans? And if we deploy on a Friday night, then we'd have to work on Saturday to cleanup any missed bugs--which sucks.

So why not ship software on a Friday?

*We might (not sure) need to make this assumption: there is one core software development team located in one timezone deploying their company's core web application.

Answer 1

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.

Answer 2

It's not just a matter of bugs. There may be other related support burdens - explaining new features to users, monitoring that there aren't performance issues.

A new release will generally mean a brief spike of support activity - so scheduling that to happen when there are fewer people available (or when there's more resentment of time taken up) is a bad idea.

Answer 3

We normally deploy on Tuesdays, then we have the rest of the week to jump on any problem. It depends also a bit on the industry, if there is no work on weekends maybe its OK to deploy Friday evening but if they are working, then its not a good idea.

To that people tend to be a bit more sloppy on Fridays (already thinking about that hot date|cold beer|both) and days before leaving for vacation ;-)

Answer 4

It really depends on your application and how busy / critical it is at the weekend.

We don't usually deploy software on a Friday, but often do so on Saturday or Sunday. We've found Sunday morning to be particularly good to minimise impact of a release.

It really depends whether you're trying to minimise the impact of any down time you need to make your release, OR mitigate any potential bugs.

You're not going to see any bugs until customers actually use the system (in most cases), so deploying on a Friday is equivalent to deploying on a Monday morning, if you have low usage at the weekend.

On the other hand, things like online shopping tend to have more usage at weekends, so you'd definitely be advised against deploying one of those on a Friday.

It also depends on your out-of-hours support policy. If you have someone on call who can roll the software back, it's less of a risk. Still, I'd rather do that during the working week.

We usually deploy stuff tuesday-thursday, preferring to avoid Monday (our busiest day) and the weekend (when a bug could sit unnoticed causing problems)

Answer 5

Never deploy on friday because:

1. It's the end of the week so people are less sharp
2. It's the end of the week so people are not available for fixing bugs
3. It's the end of the week so people are not available for answering questions
4. It's the end of the week so why would you deploy then?

Answer 6

It depends on your target group. We mainly deploy on Fridays. Our browserbased product is used globally by customers, but mainly during office hours. That means we don't really have any time other than sunday mornings if we want to make sure we don't affect any customers (india and the middle east don't get off from officework on saturdays), but generally we "compromise" and deploy Friday afternoons.

If previously worked on a datingsite where we ideally wanted to deploy new stuff around Tuesday, since activity peaked around weekends and strangely, monday around lunch.

Anyhow, it comes down to 2 considerations. 1. When will it be the least disruptive for your customers (if it's a web application) and 2. When will it fit best with the dev team for rush-fixing critical bugs.

If you are worried about your developers getting sloppy near the end of the week, your QA pipeline may be too short.

Answer 7

Strange discussion! Isn't it question of planning and avaiblabilty in case of problems?

Answer 8

We are lucky enough to make good use of time difference, we have offices spread across the world. Thus when making updates to clients we arrange it so that it is done overnight for the customer so to minimize the impact on them.

this works well when you control the implementation and deployment of your software but releasing on a web site is another animal altogether. As others pointed out already make sure you allow time for :

1. Supporting quirks and bugs that may occur
2. Supporting users in the transitions
3. Last minute hot fixes

Answer 9

I worked with a company that had a policy of deploying on Fridays; they were in Israel and Saturday is usually the last day of the working week. Anyway...

At my last company the policy was to provide to Ops the deployment package no later than lunchtime on Tuesdays and Thursdays. This means they have half a day to get it out and request minor adjustments if anything goes wrong with the last phase of pre-live QA. (Any other QA can happen at any time of the week because it's not live.)

Release to any environment except live is fine at any time, if Ops have the time to do it (of course, that should be booked in before-hand anyway) but never release to live on:

Monday- Bad, you've just come back from (hopefully a non-working) weekend and won't have everything you did last week in the front of your mind. Wednesday- Usually the least productive day of the week and sits as the "middle of the work" day. If your slot was Tuesday and you missed it due to bugs, Wednesday is probably a bad choice as you're not providing enough time to fix and test those bugs. Friday- Come on. Seriously? It's Friday. If this really needs explaining then you're not experienced enough to be doing the kind of managerial position you're in. But seriously, it's because deploying on Fridays means volunteering your clients to come in on the weekend to test your work in a live environment. For me, that beats any idiocy you might be lining yourself up for.

Answer 10

I would never plan for a friday deployment unless I was also planning to be in the office on Saturday verifying that its working correctly, if you end up deploying on a friday because of slippage you are in great danger of rushing things, far better to wait, let everyone calm down over the weekend then ship on Monday after a morning review.

If your deployment runs over the weekend then starting friday night can give you a good head start as often the office will clear a little earlier so overall system load will be lower than say Monday morning.

Answer 11

We avoid releasing code on Thursday or Friday - nobody wants to spend their Friday figuring out mission critical bugs, and the chances are that even if we do produce a fix in 1 day, it will be at least another day before it can be released, which means either working the weekend or it doesnt get fixed until next week.

Answer 12

Question: how much of application downtime is caused by application bugs (by-passed QA) and how much by a human error in deployment (forgot to restart Tomcat, etc.)?