Continuous Deployment – so much to learn

I have a lot to learn about the pattern and how to be effective at doing continuous delivery of a web app. This presentation is giving a few hints on what you need to be successful:

  1. Monitoring
  2. Testing
  3. Remediation

The monitoring portion is more than just availability. You need to be able to detect any failure quite rapidly otherwise you won’t know to which release to rollback or what to remediate. Monitoring your logs is probably the next thing I need to implement and see how good I can get this. Jez Humble talks about monitoring revenue and it is a great idea for real businesses, it just does not apply to my web app. You can monitor the number of transactions or logins instead of revenue but I will keep that as my next step. Logs first.

Testing, I have a clue on what needs to get done but the cascading of the different type of testing was not something I had in mind until I listened to this presentation. Unit testing is the first step to what needs to get done and I knew that but the next few steps are a bit more clear now.

The remediation pattern that were shown are good ones. Failure does not mean a full code rollback. You can deploy features and turn them on later. I especially liked his Facebook example where the code was there and user loging in were making calls to the back-end without knowing it. This allowed the team to see how the code/app would behave under a more realistic load. That is clever.

Now I have to write down how this is going to change my architecture for this web app. It certainly will improve the plan.

Continuous Deployment

I have read and seen a few presentations where the team works in a continuous deployment mentality. I find it very fascinating because I am in situation where it would be of great benefit to me to have this environment.

This is the latest presentation I have look at:

First reason for this CD environement: no QA team. I am responsible for product/service and I am alone in taking care of it. I have no one to check if what I am doing is good and not breaking any existing features. To achieve the level of comfort needed for continuous deployment you need to have testable code and that is my achille’s heal on this project. There was a bit of code written for a few tests but I added afew features and modified many things without modifying the test code or adding any. I need to change my mentality to get a lot more tests in there so that I can feel at ease when modifying code or adding features.

Next reason is the speed to deploy to your customer the features and change they need. When it takes week to deliver a change people become impatient and they lose respect or trust for your abilities to help them. With the current change management process we have, it takes at least a week to deliver the smallest change. This is a setup for failure and no one can feel comfortable in it. If I implement CD correctly then deploying new code should be this regular activity that no one cares to track. It is simply normal operations.

Since I love numbers, I picked up on the statistical analysis that they do to confirm that the new deployment is good. They look at the number of errors but also the number of request on each page to see if there is a significant differences. This is interesting and is very viable when you have a good amount of traffic. In my case the traffic is small enough that the smallest anomaly will create a significant statistical difference. I will have to think and read more about how to address this one so it gives me good KPIs.

The funny fact that excited me is the automation. It is funny to my project because my main goal with my project is to automate what we do to help us be more efficient. So CD is about automatind the deployment on my automation tool. I love irony.


Continuous deployment

This article is a must read:

The discipline and the level of automation to be able to continuously deploy new code is inspiring.

It may sound impossible to do right now but I think that once you start taking the first step on this path you will not want to go back. This is a lot more fascinating than the current type of testing I see done on my code. It is also more fascinating to think that you can deploy new code easily all the time than having to go through all the paperwork that I am seeing all the time.