Press enter to see results or esc to cancel.

Weekly Releases: When is the Best Time to Deploy Code

There is always risk when deploying code, however thoroughly tested your application is. Some common pitfalls include:

  • Unexpected differences between Live and Development environments (mitigated by a properly set up staging environment)
  • Human error during any step of manual deployment
  • Difficult to produce bugs (i.e. the classic Heisenbug), that are only discovered when the application is in Production.

In order to mitigate the risk involved with deploying an application, it is important to plan when you will release your code during the week. We will examine the best and worst times to deploy your application throughout the week.

The Worst Times to Release Code

Deploying code is a simple, yet potentially risky task. It would be impossible to completely remove the risks involved (however minor), so it is important to prepare, and allow time to rectify it if emergency issues occur. Needless to say, the absolute worst time for a deploy would be a Friday as most web developers do not work weekends, and are not on hand to fix it immediately if any emergency issues occur.

Top 3 Worst Times to Deploy

  1. Friday Afternoon. No one on hand to complete emergency fixes.
  2. Monday Morning. Insufficient time to prepare properly.
  3. At the end of the working day. Not as bad as Friday afternoon, but no one will be on hand for at least 12 hours in case something goes wrong.

The Best Times to Release Code

It is best to release your code as early as possible during the week, whilst being accommodating to the rare, unavoidable high priority issues that may arise over the weekend. There should be sufficient time to prepare the release, and developers on hand for several hours after in the event that an issue occurs.

Top 3 Best Times to Deploy

  1. Tuesday Morning. Monday can be dedicated to fixing any high priority bugs that may have been found over the weekend, and preparing the code for deployment (merging & tagging). Developers are on hand for the rest of the day should an issue occur. The rest of the week can be dedicated completely to developing the next week’s release.
  2. Wednesday Morning. Good for the same reasons as Tuesday, but unnecessarily breaks up the working week which may result in a slight drop in efficiency.
  3. Thursday Morning. Exactly the same benefits and disadvantages as Wednesday, but closer to the weekend where developers are not on hand.

It shouldn’t matter when you deploy as your code as it should just work.

In an ideal world, any unexpected behavior would always be detected during automated or manual testing. In reality, unforeseen things happen. Picking a good time for your deployment can mitigate a large amount of potential risk, by minimizing downtime should an unlikely issue occur.

At Mannion King, we always release mid week (Tuesday, Wednesday or Thursday), with preference to the former. We allow a degree of flexibility between these days depending on the project, and will always deploy in the mornings. Any releases that happen on a Monday or Friday are emergency bug fixes only.

Final Thoughts

Choosing a good time for your deployment is easy to do, doesn’t cost any extra time, and aids in risk free deployments. This article is a guide in helping to pick the best time to deploy, but your particular application may have unique characteristics that makes this impossible (such as peak traffic in the mornings). It is important to factor in these characteristics to decide upon a suitable time, so that you can begin to reap the benefits of lower risk deployment.

  • It also depends a lot on the application itself (like you said), especially with big or popular applications/websites. Then, you cannot rely on a ‘general’ indicator, you need to plan accordingly.

    You need a detailed plan that precise at what hour it will be deployed and when, by who, how long it will take. Then, who will test that the application works as it should. What will be tested exactly, how and by who.

    Do you need a client ‘GO’ to know if you need to roll back or not? Do you need a different roll back procedure (DB modifications, data importation to roll back, config to change)? Who will do it? How long will it be?

    Who’s in charge in case of problems? It should, obviously, be somebody that know the application and a system admin. And, what are their contact information? Will they be on site or at their home? If they’re not on the site, ensure that they tested their VPN connection or whatever they need to work from home.

    In some type of application, you could even start the deployment process days before the deployment of the final code. For example, you could need to change the content in a CMS on a staging environment, import data from somewhere and test it… Deployments can get really complicated on big projects, but the key is to have a detailed plan (and also a good team lead) 😉