The Deployment Production Line Jez Humble, Chris Read, Dan North ThoughtWorks Limited jez.humble@thoughtworks.com, chris.read@thoughtworks.com, dan.north@thoughtworks.com Abstract Testing and deployment can be a difficult and time- consuming process in complex environments comprising application servers, messaging infrastructure and interfaces to external systems. We have seen deployments take several days, even in cases where teams have used automated builds to ensure their code is fully tested. In this paper we describe principles and practices which allow new environments to be created, configured and deployed to at the click of a button. We show how to fully automate your testing and deployment process using a multi-stage automated workflow. Using this “deployment production line”, it is possible to deploy fully tested code into production environments quickly and with full confidence that you can fall back to a previous version easily should a problem occur. 1. Automate your deployment process It is often the case when working on a large, complex application that it must be deployed into a number of different environments on its journey through into production. In the course of doing this we often spend a great deal of time building the software, getting it to work in the various testing and production environments, and debugging integration problems between the application and other systems. Often the processes for building, testing and deploying such applications into non-developer environments are manual, and can in extreme cases take days. These processes are usually complex, difficult to repeat reliably, and subject to change during the development process. Sometimes they are documented, but often the documentation is incomplete or out-of-date. In some cases, the information needed to deploy resides in the heads of several key members of staff who need to come together to perform the deployment. It is common for teams to be working on several application streams that share parts of their code base, such as libraries and frameworks. One solution to these problems is to automate fully the build, testing and deployment process. Automating this process in the early stages of your project is of immediate worth. Not only does it save developers time, but it also helps detect problems with deployment early on in the development cycle, where fixing the problem is cheaper. Furthermore, automating the entire deployment process embodies a key agile practice – making your code (in this case your deployment scripts) your documentation. One benefit gained from this practice is that your build and deployment scripts capture your deployment and environment testing process, and can be leveraged to give you rapid feedback not just on the integration of the modules of your code, but also on problems integrating with your environment and external dependencies. However, automating deployment can be complex, time consuming and daunting, and it is not usually clear exactly how to go about it. In this paper we will present four basic principles, look at some practices they motivate, and give examples of how to implement these practices in order to address what we believe are the most common challenges facing automation of the build and deployment process. These principles are: 1. Each build stage should deliver working software – don’t have separate stages for intermediate artifacts such as frameworks. 2. Deploy the same artifacts in every environment – manage your runtime configuration separately. 3. Automate testing and deployment – use several independent testing stages. 4. Evolve your production line along with the application it assembles. In the following sections, we will examine the motivations for these practices and discuss the practical benefits they deliver. Proceedings of AGILE 2006 Conference (AGILE'06) 0-7695-2562-8/06 $20.00 © 2006