This is Part 1 of a three-part series designed to extrapolate on the concept of Continuous Delivery in the context of DevOps, the process flow and tools involved, and a suggestion for implementing these processes.
What’s all this DevOps stuff?
Over the last year or two, organizations with strong development teams have undergone something of a revolution. It really began in 2001 with the Agile Manifesto signalling the end of the waterfall methodology in software development, in favor of Agile tools and processes. These tools (Scrums, sprints, etc) have set the stage for what is turning out to be the ‘third renaissance’ in software development. “DevOps” – the merging of Development and Operations – viewing the entire delivery cycle of software as a single process, rather than the walled silos of old – is the stage for this new approach to application deployment: Continuous Delivery. (Read up for more understanding of Continuous Delivery vs. Continuous Deployment)
A New Approach to Application Deployment: Continuous Delivery
Enough with the buzzwords and lofty history chat. Lets get into the meat and potatoes.
Continuous Delivery is an extension of the DevOps approach to managing the software development, build, testing, and deployment process. The first phase of Continuous Delivery, Continuous Integration, has now become commonplace in many organizations. Continuous Integration allows for hot-builds of applications immediately after check-in and compilation of existing code. If the code compiles cleanly and gets the green light, it is automatically deployed onto a Continuous Integration server and is available for immediate testing; however, we have seen that most firms are still incapable of automating their deployment processes.
This has been a huge boon to the software industry. Code that is actively being developed may be viewed and tested by people not intimately involved in the development process, without any user intervention. The application appears on the CI servers within minutes of a check-in by the developer (assuming nothing broke), giving visibility into a project outside the local coterie of coders.
How does Continuous Integration extend into Continuous Delivery?
Taking this concept further, Continuous Delivery takes CI and extends it beyond just CI servers, allowing for deployment of code all the way up the service chain. Not only can code be hot deployed to CI servers, but the same code should be deployable to all test environments (QA, Testing, and Staging), and, with basic checks in place, right to Production. With a properly built environment, the same code that comes out of the CI server can be deployed all the way up the chain, without any changes to the built package.
So why do this?
The goal of Continuous Delivery is not just making updates to the environments automated. That part is easy, and has been implemented many times before using automated deployment tools like Puppet and Chef. The difference here is that Continuous Delivery takes a much more holistic approach to the problem, and looks at it in the following way:
All environments should be as similar as possible; the same packaged code should be able to be deployed on any server, in any environment, without requiring customization or manual intervention.
I’ve heard that before – isn’t it too hard?
Java applications in particular have this capability intrinsically. Applications are bundled into an easy to deploy package (JAR, WAR, EAR, etc), and the containers are by default set to accept this file as the entire application, and manage it appropriately. Generally the issues are not with the deployment methodology, but with the application itself. We’ll go into some of the pitfalls of implementing a Continuous Delivery strategy in Part 2 of this series.
There’s a great phrase you find in a lot of Continuous Deployment resources:
“If it’s hard to do, do it more often.”
Think about this for a few minutes. If there’s a rough spot in the deployment chain, does it make sense to avoid it and leave it there, like a speedbump on the autobahn? No! Focus in on it, keep going over it and smooth it out until it’s no longer an obstacle!
What benefits does Continuous Delivery bring?
The primary goal in any Continuous Delivery solution is to streamline the delivery pipeline from the developers desktops all the way out to production. With automation, proper testing, and clean configurations, the average Continuous Delivery implementation can speed up the delivery process by two orders of magnitude. Whereas before, the delivery lifecycle might be 6 months, (180+ days), a stable and well-established system can allow for software updates to drop down to a few weeks, or a few days. Removing the stress and worry about deployment into production allows for faster updates, more often, with less downtime and happier end users.
What kind of impact can I expect on our organization?
Probably the most concrete example of a successful implementation is by looking at the ‘turnaround’ time from when a bug or feature is requested on the production side of the environment, and when that bug or feature is implemented.
In a standard (ie ‘waterfall’) environment, the bug would be noted in the production environment. It would be slated for the next release of the product, and resources would be assigned to fix it. Once that cycle was complete, the product would ‘waterfall’ through QA, Testing, and Deployment, and the fix would go live with the next release.
In many organizations, this process could take months. With a fully implemented Continuous Delivery process, this could take days, if not hours.
That’s the win.
Snap! Ok, how do I get there?
Continuous Delivery requires some specialized tools and thought about how your products are packaged and distributed. In Part 2 of this series, we’ll take a look at some of the tools that are available, and look at how to start preparing your existing environment to better adopt Continuous Delivery concepts.