Continuous delivery comes after continuous integration. The idea is to be able to have fluid deliver process to put evolution of application on production. One way that looks easy and simple to do continuous delivery is to automate the process of the delivery to allow developers to automatically send their stuff on the production platform without involving someone else. But as I try to present it on my previous ticket this is the dark path of the Devops.

The good way to make the delivery process fluid is to remove useless actions and documentations but to be careful to keep important knowledge exchange between team. For example having a word document that explain every command the operator has to copy/past to do the install is not an efficient way to allow him do deploy the software and to learn how to operate it. It could be great if the document that describe how to deploy the software could be understand by all the people involve and automatically execute by the computer.

So the first step is to find a way that all team involve on the delivery and deployment of the software speak the same language. It have to be simple to write but also simple to understand by some who use it; if you already has try to debug a big shell script you know that understanding script language is not always enough to understand what a shell does.

One language I found good for that need is the state language use by tool like Puppet or Ansible. Your deployment document describes the state of each element and its dependence with the other elements. When your document is executed by the tool, it ordnance each element according its dependence and check the state of each one, executing the action to change the state if needed.

So with little experience it is easy to write, easy to execute and easy to troubleshoot.