Advertisements
The "continuous delivery" process of building, testing and deploying software is relatively unknown -- but that could be about to change thanks to the publication of a new book on the subject. "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation," (Addison-Wesley Signature Series (Fowler), is written by Jez Humble and David Farley, and is available from major booksellers The basic idea behind continuous delivery is that by automating the build, deployment, and testing process, and creating improved collaboration between developers, testers, and operations, delivery teams can release software updates in a matter of hours--sometimes even in minutes, regardless of the size of a project or the complexity of its code. "Think of continuous delivery as Agile on steroids," said David Thomas, a software engineer at Rally, a leader in Agile application lifecycle management. "It is an extreme form of agile and lean software development that seeks to minimize waste and maximize speed and efficiency." Clearly, continuous delivery is not for everybody. "But, if you're in an environment where you need or want to deploy changes to production 50 times per day, continuous delivery will enable you to do so," said Thomas. This is still very cutting-edge stuff, he added, noting that the concept of continuous delivery only began surfacing in conferences and forums about a year or two ago. "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" covers build and deployment automation, continuous integration, test automation, managing infrastructure and environments, configuration management, version control practices, data migration automation, and even governance, wrote Humble in a recent blog. The book has two primary themes: automation and collaboration. Delivering software of any complexity involves people with a bunch of skills: testers, developers, and sysadmin / operations personnel," said Jez Humble. The last group of people often gets left out of the process of delivering software until the end, and even testers are often not as heavily involved in the development process as they should be. "It's a pattern we see over and over again when helping people deliver software, and it inevitably leads to unacceptable numbers of defects, poor architectural decisions, and lengthy and unpredictable delays to getting releases out of the door," said Humble. One of the main aims of the book is to provide a framework so everybody involved in the delivery process can work together from the beginning.
