Deployments per Week

One of my Software Development idols, Gojko Adzic, retweeted MindMup’s tweet regarding their high amount of deployments:

@MindMup: fun fact: From January 2013 to 22nd September 2014, there were 475 deployments of MindMup source code to production. http://discover.mindmup.com/press#facts

That’s a whopping 1.06 deploys per work day!

So I decided to look into our deployments per week - just to get an approximate comparison. We have a several different systems, but to make it a fair comparison I will look at only the call-related services we provide.

I go into this expecting that we will have more deploys over time than MindMup: just today I’ve deployed to production 4 times (and 5 times to our test environment).

The following are the results for the last 4 weeks (which is a period I am sure we have reliable statistics for):

Graph showing deploys to staging and production environments for Justfone over 4 weeks.

We see an average of 4.4 deploys to production per work day. It should be noted that our deploys to the staging environment are entirely automatic. Sometimes we will have a lot of staging-deploys close to each other, which we will bundle into a single production deploy, resulting in a big difference between the two.

It is very obvious from the graph that the number of deployments depends on what kind of tasks the team members are working on. Some weeks have a lot more deployments than others, but I think it is pretty clear that we deploy a lot.

Is it possible to deploy too much? #

Have we reached a point where too little value is provided with each deployment? The central balance to find here, in my mind, is the one between time spent per deployment and new stuff per deployment.

(time spent per deployment)/(new stuff per deployment)

The only conceivable downside to deploying too often is ending up with a short-circuit of the feedback loop. If a deployment takes too much time, relative to how much time it takes to produce a new feature, the mind of the developer will be elsewhere once feedback is given by the system, making it harder to correct course, when needed.

Ideally, this shouldn’t cause trouble too often (as most issues should be caught during testing), but it is worth noting that many deployments require fast deployment times. This is something we continuously work to improve, in order to make sure that it does not become a problem.

Is there such a thing as too few things per deployment? Ideally, an update should only be made if it results in more value for the customer. The deployments we make at the moment are very small, but each gives a tiny amount of new value to the customer, which leads me to think that we are doing something right.

 
11
Kudos
 
11
Kudos

Now read this

Faster web apps by hiding processing time: a lightning talk

This is your web server: This is a client, making a request to your server: A web application consists of both the client and the server. The client might be a browser, that beautifully renders the HTML, CSS and Javascript you send back.... Continue →