Sep 20

How come you should not deploy software on a Friday? I’ve been pondering deployment issues and looking into best practices for when to time software releases (time of day, day of week). I am not considering how often to release (I think short iterations are best). It seems to me that the true answer is always highly dependent on individual organizations. Below are some points to consider which may make a good case against releasing web applications on a Friday. Again they may not apply to your organization, but you might consider them for other times/days also.

  1. In some methodologies, the release itself is pretty much a non event because of a rock solid integration environment and continuous integration practices. However, it is still almost impossible to exactly predict user reaction and usage. Thus having support (software, network, system, etc.) available can be crucial after software is released. And typically the best support personnel do not work on the weekends or late at night.
  2. A lot of groups end their iterations on Friday. Thus if they are also under the gun to deploy, there is the possibility that they may be rushing to finalize those last features. This can create a loss of quality and also create a fatigued team. Both of these risks are not beneficial to deployment. So if the team hass been pushed to finish the iteration, you may want to give them a chance to recover before you push them to do a major deployment.
  3. Related to the issue above is the situation in which the production environment is a complex one. Deployment may become a large process in which many changes have to occur at once to support the new features of the release. This will require planning and it can suffer greatly if the rush to finish the iteration takes priority. One database table change that gets missed because of the rush to meet a Friday deployment deadline can cost thousand in e-commerce. If only the planning had been better. (One way to avoid this is to make this part of the iteration with a proper LOE and priority). Scott Ambler discusses dealing with complex deployments in this Planning for Deployment.
  4. How do your users like Friday releases? Is Friday a critical time for them to use the software? If so, then they may not like the hassle of figuring out new/changed functionality.

Do you know of any other reasons to avoid certain times/days of the week for deployment?

4 Responses to “Don’t Release on Friday”

  1. We, too, do usually not release on Fridays (at least not in the afternoon). As we’re a small team with no dedicated 24×7 support we try to stay clear off evenings as well. Usually we do not release later than 4:30pm to have at least 2-3 hrs till the core team goes home.

    So, for us, its not so much about our users (in this case) than about us being able to support the app after deployment. We stick to this even though we hardly have any issues after a release :-)

  2. dcpatton says:


    It makes complete sense to deploy the way you are doing it considering how crucial your members of the team are. Congratulations on not having any issues after a release. One question for you (and others) that I should have brought up in the post is “Have you ever had to rollback a release?”. That is something few teams consider when deploying. I’d love to hear others approaches.

  3. Oh, yes, we had to rollback releases. How we deal with rollbacks depends on the size and criticality of the release. A normal release (which we do 2-3 times a week) is just running cap deploy:migrations. If it breaks, we roll back using capistrano. No deal.

    If we have a bigger release with tons of migrations and infrastructure changes part of our release preparation is not only to write a very detailed release HowTo but also a very detailed rollback HowTo. We make sure we try the rollback on our staging environment first.

  4. Shawn Scott says:

    Yeah I learned this lesson the hard way many years ago in a development shop I worked in. We used to deploy around 2pm on Fridays until the one week everything went wrong. It took so long to get things fixed, that everyone mutually decided they didn’t want to risk spending their Friday evenings in the office like that again. From that point on we did all major releases on Thursday just in case things didnt behave as expected.

Leave a Reply

preload preload preload