Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Automation processes for continuous delivery

Implementing continuous delivery requires automation processes. Here are tips and tools to help smooth the implementation process.

Continuous delivery is a process designed to dramatically speed up the delivery of software into production. Martin...

Fowler defines continuous delivery as an approach to building software so that it is ready for release into production at any time. He also points out that two key aspects are necessary to achieve continuous delivery: automation and a collaborative culture (where everyone involved in the software development lifecycle is part of the team). In my first article on continuous delivery, I described how the process, although it is a disruptive technology, leads to continuous improvement. In this article, I discuss the automation process and the automation tools needed to implement continuous delivery.

Like automating any process, automating continuous delivery begins with discovering and documenting the manual processes, from development through deployment. This may be a bit complex because it involves different areas within IT, including development, test and quality assurance, systems administration, and operations. Moreover, each team has a different focus, which adds to the complexity. Once the processes have been documented, analyze them to determine the most time-consuming and error-prone components. These components are the most important candidates for automation. Because continuous delivery involves multiple processes, each with a different goal, complete automation will involve multiple tools, including version control, configuration management, code review and monitoring.

Continuous integration, the basis of continuous delivery, is the most critical process to automate. Continuous integration is a process whereby developers check the code from their individual branches into the main line of code multiple times each day. These integrations must be checked against the version control system and regression tested against the main line of code.

Let's look at some of the most popular continuous integration tools. Among the open source tools, the most popular are Hudson, Jenkins and CruiseControl. On the commercial side, Microsoft's Visual Studio Team Foundation Server (TFS) is widely used. All of these products integrate with automated functional and unit test tools.

Hudson, a popular open source continuous integration tool, was developed to focus on build and test and on monitoring external jobs. Two of its most important features are its ease of use and its many plug-ins. Hudson is simple to install and configure, and has a self-explanatory user interface, which shortens the learning curve.

Although Hudson is primarily designed for Java, plug-ins are available for C#, Python, Maven, Ruby and others, and it integrates with Selenium (also open source) to create functional and regression tests for Web applications. Plug-ins are also available to integrate with software configuration management tools, unit test tools, security tools and code coverage and analysis tools. Hudson provides a tool for writing plug-ins, and integrates with various application servers and virtual environments.

Jenkins, also an open source continuous integration tool, provides many of the same features as Hudson. Jenkins is easy to install and configure and provides plug-ins to integrate with most test tools, servers and environments; it also provides a tool for developing plug-ins. Hudson and Jenkins both have their origins with Oracle, so they are quite similar, with only slight differences in the plug-ins.

CruiseControl, one of the original configuration management tools, is used widely in the software development industry. It supports most test tools and can be used on most application servers and virtual environments. It is highly configurable using a central XML configuration file, which can be edited through its own GUI or directly. However, configuring CruiseControl is much more complicated than configuring Jenkins and Hudson. CruiseControl's strength is its monitoring tool. It continuously monitors the SCM servers and triggers a new build when changes are detected. Its notification feature is also its strength because it supports most social media including email, Jabber IM, RSS feeds and blogs.

On the commercial market, Visual Studio TFS is a full application lifecycle management tool. It provides all of the important features of a continuous integration tool, including configuration management, version control, unit test tools, defect tracking and monitoring. It provides extensibility and can be configured to work with most tools. It also includes integration with Microsoft's project management tools, including Project and Excel, and it integrates with SharePoint by providing a team portal for centralized communications.

Several factors are critical to implementing continuous delivery successfully. First is being able to automate integration into the mainline; every developer has to commit to the mainline every day, rather than have extensive branches that exist over a period of weeks. Second, building is constantly occurring, at each commit to the mainline. This includes automating smoke tests at the end of the build so that obvious integration problems and other errors are caught right away. Last, because the focus is on delivering working software, developers, testers and release engineers have to work closely together to make sure that every commit and build is tested and validated.

Next Steps

Read more about continuous delivery in ALM

Learn about why one CTO is advocating for automated tests and continuous delivery

This was last published in March 2015

Dig Deeper on Software Deployment Management



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What are some common issues your enterprise has encountered within the implementation process?
In my business, the most difficult part of the implementation process is getting everyone on board with the changes and ensuring everyone is on the same page. It is vital to your success to make sure all team members know what is going on and are supportive of the new system and process. A team divided will fail so for us implementation is about overcoming differences in option and view so everyone can work together.
Thanks SarahJo,
Great feedback! Any tips for getting everyone on the same page? 
For instance, I've been hearing folks lately saying the first thing is to make everything very visible. Get all the cards on the table so to speak. Making sure everyone has the chance to see the reasoning behind the changes and to get their questions about the changes answered seems to help. Would you agree?
I've also heard the experiment strategy is helpful. (Matt Heusser brought this up in a podcast that should be going live on SearchSoftwareQuality next week) Position the new changes as an experiment. Dissenters will go along with it if they think it will only be two weeks. And if they see benefits in those two weeks, they'll keep going. But if they don't, then you have the chance to tweak processes and try an improved experiment later. Have you tried that?

Thanks again,
I found it's very helpful to give everyone a voice and to make team members feel like they are part of the process from the beginning. I am met with less resistance when I let everyone have a voice- rather than telling everyone what they can and cannot do.
There is tremendous value if teams can get to the pont where the building, deployment, and potentially the provisioning of servers in test environments can be had at a click of a button.

It is improved when running of automated checks, end to end and api level testing, and helping to identify releases that are ready for deployment to production.

However, I still advocate for developer awareness, and not rely on Automation to make the final go live to production call.
We've done something similar to this, although we didn't call it Continuous Delivery. The biggest issue we found was keeping up with code peer reviews.