The story of the magical delivery

So we have found a kind of language every one involve on software deployment could speak. But what do we want they say with it? Which story we want they tell? Software deployment could be seen as house building.

  • We have first the foundations that come with electric power, water arrival and dirty water evacuation. For a platform it’s the VM, the network connectivity, the NFS resources … and all the tools that are needed to manage the platform: supervision, ntp server, ssh rebound, firewall, load balancer …
  • After that come the structural work: building the main wall, roof and adding windows and doors. For our software it’s the installation and configuration of middle like Apache, Ngnix, MySQL, Tomcat … it’s putting the platform in the state it’s ready to receive the software write by the developers.
  • And finally we have the finalization of the house to make it a place where we can live. For our platform it’s the deployment of the software that implements our service.

Usually architects define the platform structure, developer build their software then integrators build all the packages and write the documentation to allow operators to build and deploy the full platform.

Operators have usually the better understanding of the infrastructure structure, so it could be better that they define how to build the foundation. And to simplify the work of the integrator, it seems better that integrator have build the walls before developers start to build the kitchen. But as we want to stay agile and as we build software and not a house we want to be able to let everything evolve to reach our goals.

A good way to reach that goal it’s having all teams involve on the deployment working together from the beginning and sharing the deployment process. So operator and integrator will work together with developers to build their work environment and we will use the same environment process on all platforms on the way to the production one.

Do we have time for that?

Asking operators and integrators to work with developer to create build environment could seems to take a lot of time before starting to produce something. But if you think agile, at the start of the project, usually developers have common needs. So if you have a catalogue of common deployments write with your chosen language, it could be really quick to start your platform. Writing the items of this catalogue could seems a big job especially if you want to have a team in charge of the catalogue that define those items. But the good way to manage those kind of catalogue is to use web2.0 and social services. If you create a simple service that allow people to propose their deployment process for every task, to comment them and say which one they use, you will have quickly a knowledge base that will grow up itself. No need to have “expert” to manage it.

Who to implement continuous delivery?

So the first step is to choose a language that every one could learn. Right now I think the best choice is Ansible but there are a lot of alternatives. But I think a good tool have to provide some capabilities:

  • Open Source: You want that every one use it, if you start to introduce license price you will start to limit the use of the tools to reduce the cost of your project. An open source tool let you organize your team as you think you need to reach your goal. Another good thing with OpenSource it’s you became part of a community that share same goal and issue.
  • State machine, idempotent: That is a simple way to write understandable installation process and easy to troubleshoot. It allows you to manage with the same process update and fresh installation.
  • Parameterization: You have to be able to use the same process on different platforms like development, qualification, and production… so your delivery process have to use parameter set that will change against each platform.
  • Shared playbook: All people involve on the deployment process should be able to access and enhanced the process. A good way to do it is to use tool like SVN or GIT to share playbook a track change. I know developer prefer GIT but often SVN is easier to use for operator and we don’t really all the feature that offer GIT.

Having tool is good but not enough

Choosing a tool is not enough make teams work together on the deployment process. You have to define who is in charge on which part on the process. For example, operator will take care of the OS and network configuration, integration will manage middleware and developer will create the deployment process for their applications, as they know how to configure them. But be in charge of a part of the deployment process doesn’t mean the team is the owner of this part of the process or this only one allow to modify it. It just means that this team has the responsibility to make this part work. They can accept or refuse enhancement or proposition of the other team. Having the responsibility to make it work doesn’t mean neither that they are the only one allow to execute it. On each platform only the operators of this platform will be allow to execute delivery process on it. So for example, on developer’s platform the operators could be the developers themselves. If you have multiple teams in charge of executing stuff on a platform, quickly nobody will be responsible of having the service up and running.

What is the best recipe to implement continuous delivery?

There is not such thing as the best continuous delivery solution. If you want that your project use continuous delivery you have to let the people involve in it find a way to organize themselves and discover how to work together. The continuous solution can’t be imposed it have to be build together. It’s not something that will work in five minutes; you have to accept to take the time for each team to learn how it will change their work. You will have issues with continuous delivery, what is important it’s how you will solve those issues.