Automated Deployments

This is the thirteenth blog of a series of posts about the topics Continuous Integration and Continuous Delivery. It explains how important continuous integration is, to deliver software in short iterations to the customer with a high quality standard.

The basis of Continuous Delivery is a completely automated deployment. It should not depend on single persons and manual clicks whether or not software will be delivered to the customer or just published on a staging server for quality tests. How often have I heard "we cannot deploy because X is on vacation" or "it is too high effort to deploy it now". In order to deliver new features to a customer on a regular basis, automated deployments are a must-have.

Of course, depending on the complexity of the software, automated deployments can be difficult to set up. But Microsoft provides, for instance, already an extensive set of tools for that. In the web environment MSDeploy and MSBuild are the most important once. Besides copying the application assemblies and files, MSDeploy can create automatically up- and downgrade scripts for the databases. Further details about the features of MSDeploy and the deployment process can be found at Enterprise Deployment Tutorial.

In most of the companies there are even organizational boundaries between the software development and operations staff. It is very important that the responsibilities are clearly defined. The operations team provides the mechanism for automated deployments but should not be needed during a regular deployment nor have any knowledge about the exact contain of the deployment package. They should be just responsible for the infrastructure and deployment process itself. The creation of the packages has to be in the hand of the software development team and, of course, is completely automated like mentioned before.

This approach has many advantages:

• The development team is responsible for the software where they have a deep knowledge.
• The development team does not have to investigate problems based on the filtered details from the operations team. They get full access to the tracing information for their application.
• The operations team has is focus on their competences, the infrastructure.
• The operations team can be easily scaled and shared because they do not have to build up the application knowledge anymore but just provide managed IT services.

Continuous Delivery is not just about delivering new features to the customer. It is also even more important to hand over the software regularly to the testing team. As faster they can test new features as sooner we know about certain problems, bugs or even architectural issues in our application. I have seen plenty of times that the software has been developed and handed over to the test team a few days or weeks before delivery. After that when bugs have been found, the panic started because they not just had to be fixed but also re-deployed and re-tested. This all could have been prevented by continuously deployment and testing from the first day of development.

This all should just explain how important automated deployments are and that they are the basis for Continuous Delivery.