Yesterday evening I attended the second of two excellent presentations on continuous deployment hosted by Agile Richmond, who recently organized the Innovate Virginia conference at Lewis Ginter Botanical Gardens. Paul Duvall gave an excellent overview of Continuous Delivery in the Cloud at that conference and, last evening, Mike McGarr gave a great talk on Continuous Delivery as a concept, generally, and he went into detail about a number of the available tools.
From the description of Mike’s presentation on SpeakerRate, “Continuous Delivery is a collection of principles and practices aimed at addressing the problems teams typically face when releasing changes to production. By applying rigorous automation, testing and configuration management, teams are able to confidently and consistently deploy changes from version control to production without fear.”
Much like TDD produces consistently better code, Continuous Delivery practices produce consistently more stable deployments. Where the more traditional approach tests code and deployments only after a lengthy period of development, software developed using Conntinuous delivery practices is continually subjected to a battery of tests. Ideally, each “commit” of source code changes triggers a testing process which provides immediate feedback to the developer as to the continued correctness of the code from both functional and deployment perspectives. If something changes that prevents proper deployment, the developer (and the rest of the team) is immediately made aware of the deficiency. Effectively, continuous deployment elevates deployment issues to the highest priority while simultaneously reducing the risk of a serious obstacle to deployment to nearly zero. The big, unforeseen deadline-defying “oops” becomes a non-issue because there is no big deployment event. The release deployment is one of hundreds or thousands of similar deployments.
In his presentation yesterday evening, Mike gave a thorough overview of the entire process and challenges the development team will face as they attempt to move toward a continuous deployment methodology. He spoke at length about unit, integration and acceptance testing as part of the continuous delivery pipeline. He introduced several tools such as FindBugs and CheckStyle which monitor the quality and character of the code itself. And he went into detail about Puppet, Chef, and a new provisioning tool called Ansible which requires only an ssh connection to a provisioned machine to be able to do its job (as opposed to Puppet and Chef which require a resident agent on each provisioned machine). In addition to the tools which make Continuous Delivery a more tractable thing, Mike stressed the importance of making the pipeline a more traceable thing as well via software such as Nagios, Graphite, and StatsD.
Paul Duvall, in his presentation at Innovate Virginia, touched on many of the same topics and tools but was careful to send the audience home with the non-technical takeaway that Continuous Deployment, effectively, makes delivery and deployment a “business decision” which is removed from the concerns of the development team. This statement obviously carries with it a presumption that the suite of tests is both rigorous and complete, but the point is well-taken. If you have a set of requirements, a test suite that indicates that your code meets the requirements, and a system which can deploy the code whenever it’s needed, then, essentially, there’s no great need to ask for the blessing of the development team before you release a new “version” of the code.
Paul’s company, Stelligent, has developed a pipeline that they are able to leverage to help their clients more easily transition to a continuous deployment model of development. He makes a very compelling case for the approach to the software lifecycle in a general sense and, specifically, for a test-driven approach not only to the development of code but to provisioning and deployment as well.
Mike is a software engineer and practitioner of the continuous development approach to software development. He’s very recently been hired at Blackboard to make use of his expertise in continuous deployment for Learn, Blackboard’s flagship product. Mike went into detail on each aspect of the process from the idea to the end user and demonstrated a depth of knowledge in every aspect of the pipline.
Much of Paul’s insights have already informed choices and recommendations I’ve made since I saw him speak. I’m confident I will shortly be able to say the same for the many noteworthy takeaways from Mike’s presentation as well. I’m grateful to both of them for their engaging presentations and to Agile Richmond for giving them a forum.