Fork me on GitHub

What’s DEPCON?

The deployment readiness condition (DEPCON) is an alert state used by IT departments to rationalise the efforts to bring the application’s changes to the production environment.

Continuous Delivery is a great idea but with a lot of colateral damages, becoming too many times Continuous Disaster. With DEPCON we want to use the great Continuous Integration tools restricted to delivery periods, determining the Deployment Condition by the frequency of its deployments under a controlled and authorised by the board deliveries.

The DEPCON system was developed by Serveis Informàtics Corretgé.com SL with the goal of organize the deployment of Web & Client/Server applications. It prescribes six graduated levels of states of alert, dependening the frequency that a deployment is required. Usually the deployment frequency is changed because there are bugs in the production system or by requirement of the Product Owner.

Each DEPCON level has an “owner” in the company. A change of DEPCON level, must be approved by the level’s owner. This document made recomendations, but is better to adapt it to your company structure and dimension.

Back to Top

DEPCON levels

As the military norm DEFCON has 5 levels, in DEPCON we have 6.

Everyone has a predefined frequency and a board level authorisation requirement.

Deploy an application requires resources, and is preferible to planning when we will expend these resources. To change the frequency, we shall change the DEPCON level modifying the DEPCON.yml file in the root of the project and commit with a clear message. If the author of the commit is the responsible of the level it should be better, if not is possible, adding a By Order disclaimer is enough.

DEPCON 0

image

DEPCON 1

image

DEPCON 2

image

DEPCON 3

image

DEPCON 4

image

DEPCON 5

image

Back to Top

The DEPCON file

At the root of the project we will have a DEPCON.yml file where, at least, contains the current DEPCON level:

currentLevel: 4
levels:
  0: ZERO
  1: HOUSTON
  2: HURRY
  3: CALM
  4: SPRINT
  5: VERSION

Could be interesting that every DEPCON change has a dedidated commit made by the DEPCON level owner and a very clear commit message.

In the future, we can review the history of the project viewing the git log of this file as:

git log DEPCON.yml

Back to Top

Best hour of the day

Between 6:00 and 9:00 UTC Is the best hour for companies that offer services for European and American users.

This picture shows the Day and Night World Map at 9:00 UTC on July 1st. You can try your best hour of the day at the Time and Date website.

image

Back to Top

Best weekday

I agree totaly with Michael King in his post “Weekly Releases: When is the Best Time to Deploy Code”, Tuesday is one of the 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.

References:

Back to Top