Published on 25 July 2013 by

Companies that want to introduce new features to customers quickly are either already practicing continuous delivery or working towards it — or they should be.

That’s because continuous delivery of small frequent changes into the production environment — and testing all the way through — helps a company:

  • discover whether customers respond well to a change
  • lessen the risk of each change
  • plan change better

Continuous delivery is significantly different from the traditional “waterfall” model of software development, in which software is developed, tested and delivered in large chunks. So doing continuous delivery effectively requires the right tools. Some are the same tools used in traditional software development, but others are especially helpful for moving through the specific stages of continuous delivery.

We hope this list helps you figure out which tool choices are most appropriate for your company’s business. We’d also love feedback! If you have opinions about any of these tools, let us know in the comments section.

Continuous Delivery: Physical Fitness for Software Companies

First of all, let’s look at why continuous delivery requires specific tools.

The value of delivering smaller chunks of code into production, and testing them there before introducing more changes, is clear: You get to see how specific changes affect your system before introducing more changes that depend on previous ones.

To get there, though, you have to move code from the developer’s desktop environment into the testing environment — or environments — and then on into production. All these environments have to be configured the same way, or you run the risk of finding that code that worked in QA , for example, breaks in production.

The ability to do this is, in fact, the actual definition of continuous delivery, says Eric Shamow, a recovering sysadmin who’s now methodologies lead at Puppet Labs.

“When you can spin up an application in any environment in your ecosystem with any version of your application code — on demand — that is continuous delivery.”

Eric likens this ability to becoming physically fit. “Getting good at writing code that doesn’t fail is like training a muscle to be strong and flexible,” he said. “Initially when you start doing this [continuous delivery], the build breaks all the time. Then everyone gets good at writing code that doesn’t break the build, because they can see what the sources of the breakages are.”

So with no further ado, here are the tools — the treadmill, free weights and cable weight machines — that will train us to flex our continuous delivery muscles with greater strength and effectiveness.

The Tools of Continuous Delivery

First, a cautionary note: It’s not all or nothing. You don’t need to assemble a complete continuous delivery toolset to get started. Adopting even one of these tools, and the practices that go with it, can make a big improvement in your software delivery process. “In fact,” says Eric, “incorporating all of them before you are ready could be just as big a problem as having none.”

1) Version control
This is the heart of continuous integration, says Eric. “Every change must go through a version control system, and every change must be attributable to a person.” When something goes wrong, you’ll know what to check, and who can help fix it.

The version control tool keeps a record of when every feature, add-on or other change is merged into the trunk — the current, updated code base. It allows you to make sure that every change in every branch of your code gets tested against every other change. Without a version control tool, you run the risk of discovering that code that ran fine in its own branch collides with code from other branches, and breaks the whole.

A few of the best known version control tools: Git, Subversion, Perforce and Mercurial.

2) Code review
You need a tool that enables you to step through a piece of proposed code and see what the changes are, compared to the existing code base. It should allow you to mark changes, noting which are acceptable and which are not.

Some version control tools — Git, for example — include the ability to review code. So does Stash. Gerrit is a free code-review tool that integrates with Git.

3) Metrics
Continuous delivery is about shortening your test cycles — a process of continuous improvement. To make continuous delivery effective, you need to continually monitor your testing environment so you can figure out how to improve it.

“If you’re going to choose one tool to implement first, this is it,” says Eric. “Because you can argue that continuous delivery is about turning the software release process from being an emotion-driven process to being a data-driven process.”

Rather than arguing whether testing feels like it’s going better, a software development team needs to collect data on its processes to see whether its performance is actually improving (or deteriorating).

Some well regarded tools for collecting software release data: Graphite, Logstash, Nagios and Splunk.

4) Configuration management
As we said earlier, continuous delivery requires that the developer’s environment, the test environment and the production environment be configured the same way. For example, a new version of your application may require changes to the settings on an Apache server. Those changes might have to be made ahead of running the new code, “and there could be 20 of those servers, or hundreds,” Eric said.

Shameless plug alert: This is exactly what Puppet Enterprise does (and more!).

5) Orchestration
Once your environment is configured, you may need to roll out your applications in a specific order. That’s orchestration. As with any task, automating orchestration vastly reduces the possibility of human error, and makes it possible to scale far beyond what people could do manually.

Again, here’s where Puppet Enterprise can help. The latest version includes an orchestration engine powered by the newest version of MCollective.

6) Dashboards
Continuous delivery isn’t a one-person show. The entire team needs to see, from moment to moment, if the build is red (broken) or green (working), and what’s actually been released into each environment.

A dashboard should display the status of your test environment and production environment. It should show the status of every node, both physical servers and virtual machines. If you are using Puppet Enterprise, you should make sure the console is on your dashboard, so you can monitor configuration status.

Bamboo and Jenkins are the dashboards of choice for many sysadmins we know.

Continuous Delivery: Take It a Step at a Time

Going all meta for a moment, we suggest you take an incremental approach to adopting continuous delivery tools and practices. Choose the one that seems like it offers an answer to your most urgent needs, begin implementing it, and see how your processes — and your team — respond. And measure your outcomes. Once your organization has accepted and integrated the new tool and process, it’s time to look at introducing the next change.

We really do want to hear your experience with specific tools and practices - please add your comments below. We may follow up with you for a future post.

Learn more:

Share via:

Add new comment

The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.