Blog Post

Questions about continuous delivery

Monday, November 6, 2017 1:51 PM

"Continuous delivery" is

is a software development discipline where you build software in such a way that the software can be released to production at any time.

Every software have to be delivered to the consumer in some way. We can have a look at company and judge how mature is their delivery process. I have the pleasure to learn on multiple different companies and study their deliver techniques and also I have been able to use different tools for delivering the software.

 

I have noticed common trend in many companies:

The terminology used by developers and managers (product owners) means something different. For our case we take a task is assigned to developer my manager to deliver a new page on website with all required details. Now what is the interpretation of I am done? 

Manager will ask also: How long it will take you? ie what is my cost for this page?

Developer:

My work is done when my work has been accepted to code base.

Management:

Page is published live environment and i get my required business value.

 

Missed from scenario

How does the code get to production?

Setting up measurable continuous delivery

Every company has some form of delivery. In some cases the new version gets live every 3 months in come cases every 10 minutes. It depends on the company to decide what is its process. 

 

Common lie we tell ourself or our boss is

It cannot be done/changed

The question we need to ask is

Why it cannot be changed? 

Common answers to the posed question 

  • It costs time and we need you to deliver functionality
  • Because I am not allowed to touch this process
  • I do not have access rights
  • Only this person can do this
  • Only this person has the rights to do this
  • Our process already works

 

In order for us to deliver our code faster to live we need to adapt not only our processes but our selfs too. It is not good for anyone when we do something same way and never improve.

 

At this point we should take stock of all what we want to achieve from our process.

Stock taking

Lets analyse our current process. We need to ask ourself without personal bias some hard questions.

Cost related questions

  1. How long does it take to get code live in people time?
  2. What is the cost of delivering new code to production?
  3. How difficult it is to deliver my code to live production?
  4. How many people does it take to get the code live?
  5. How easy it is to roll back the change?
  6. What is the cost to the business when application have major bug ( issue )?
  7. What is the cost to the business when application have minor bug ( issue )?

 

Business related questions

  1. How fast do I need to deliver code to production? 
  2. Can anyone deliver the code?
  3. What is the repeatability of the process
  4. Are there knowledge silos
  5. What is the sign off process
  6. What is the cost to the business when application have major bug ( issue )?
  7. What is the cost to the business when application have minor bug ( issue )?
  8. Do I loose business because feature is not there?

 

Once we have answered the questions we should define the process and write it down. This will become the initial document defining the process for continuous delivery. This document needs to be living document.

Everyone should be able to read the process and it needs to be visible to all who have something to do with the process. Any change to this process have to be captured in the document.All people involved with continuous delivery should be able to raise questions and propose better and faster solutions