“Continuous Delivery” First Impressions

I finally picked up a copy of “Continuous Delivery” (http://amzn.to/9NNsd8), the latest in the Martin Fowler Signature Series from Addison-Wesley.  I have been really looking forward to this book ever since seeing the table of contents and some early drafts online. 

Full disclosure here: I’m only about a quarter of the way through it as of now.

I went into reading this book with high expectations – anyone who is interested enough in continuous delivery to write a book about it simply must be extremely passionate about it.  They had met my expectations when on page 5, I read this sentence: There should be two tasks for a human being to perform to deploy software into a development, test, or production environment: to pick the version and environment and to press the “deploy” button.  This sentence perfectly sums up my philosophy exactly around deploying software.  This is a critical piece of the puzzle with projects that leverage agile philosophies such as “deliver early and often”.  If you are going to be deploying often, you had better get it down to a science, and it had better be simple, fool-proof, and fully automated.  I firmly believe this is a “must-have” for our custom development projects, and the larger the project the more critical this concept is to the success of the project.  I’ve seen larger projects spend significant (20%+) amounts of their total effort in just attempting to manually configure and deploy software to multiple environments over and over during the project lifecycle. 

My impression thus far is that the authors are very knowledgeable about continuous delivery as a topic, and have a pragmatic take on it.  I also appreciate their analysis of how DVCS (distributed version control systems) play into the practice of Continuous Integration.  This has been something I’ve struggled with in terms of seeing the value of a DVCS – if you have branches everywhere, and no real mainline trunk, how can you really do CI?  I appreciate their analysis and recommendations, and I look forward to Chapter 14, on “Advanced Version Control”. 

I believe that anyone who has gone or will go through the process of releasing custom software inside an enterprise, especially a large enterprise, could get some real value out of this book.  Their philosophy and practices are well thought-out, and clearly based on real-world experiences.  Not just code developers either – there are chapters on data and infrastructure delivery and management as well that I haven’t yet gotten to, but appear to have valuable patterns that can be used by people responsible for these aspects of software delivery.

To summarize, even though I’m only about a quarter of the way through it, this is looking like a very good read, and I look forward to the future chapters.  I’ll post a final review once I’m all done.


Visual Studio Lab Management

We frequently work with testing and quality assurance teams in many different organizations both large and small, and often these teams do not have tools or formalized processes for managing virtual testing environments.  Their testing environments are frequently a set of machines that they manage manually, and teams have to tread carefully when managing deployments of new code to these machines.    Often we see that teams are spending significant amounts of time in creating, configuring, versioning, and deploying to the machines that make up their test lab.   These manual processes are also very disconnected from the rest of the application development lifecycle, and can be unpredictable and error-prone since people are executing these processes.

Fortunately, Microsoft has been working on a tool integrated with Visual Studio 2010 and Team Foundation Server 2010, called Visual Studio Lab Management.   Lab Management provides a platform for managing virtual testing environments, which reduces cost of manual efforts by automating the workflow of creating, managing and deploying to virtual testing environments.  Lab Management uses both Hyper-V and System Center Virtual Machine Manager (SCVMM) as the underlying technologies for the virtual machines. 

You can think of Lab Management as enabling a “private cloud” of virtual test environments in that is integrated with the build, test, and defect tracking processes you may already be using in Team Foundation Server 2010.  For example, you can provision and ready multiple environments for testing so that build scripts can target a specific lab configuration at build time.  Think about that – you execute a build process, and the QA lab environment is created, and the application is deployed to that environment.   There is also integration with the testing tools, so unit, load, and other automated tests can be executed against the newly-created VMs.  This represents a tremendous benefit to teams in terms of lowering costs and reducing risk.


This is just one key feature of Lab Management, and I’d encourage you to read more here:  http://bit.ly/cJnVjL and there is some good information from Brian Harry here: http://bit.ly/aAjQOw

I’m blogging about this today because Microsoft announced this afternoon at VSLive! that the final version of Visual Studio Lab Management will be available at the end of August.  This product will be available at for existing or new Visual Studio 2010 Ultimate with MSDN and Visual Studio Test Professional 2010 with MSDN customers. 

If you are interested in Lab Management, I would encourage you to download and try the trial located here: http://bit.ly/cJnVjL (scroll down and click “Try Me”) or contact me at ryan.dorrell@agilethought.com