To achieve the cutting-edge speed and agility promised by DevOps, you need to choose the right tools to enable automation across all aspects of development, production, and operations. Indeed, according to a 2013 study by Puppet Labs, more than 80% of high-performing software-development organizations rely on automated tools for infrastructure management and deployment. That means you probably already have many of the tools used in DevOps environments, but are they the right ones for your organization’s needs?
Take a strategic approach
There’s no one-size-fits-all approach to selecting the right DevOps tools for your needs. Your business requirements, your IT group, your budget, your legacy systems and workflows—all of these are unique to your organization. And so is the criteria for selecting tools you’ll need to maximize the benefits of DevOps.
The key is to create a strategy about what’s important to your company. If collaboration is your goal, for example, the right tools can encourage your teams to do the right thing. Does QA have to wait for the provisioning of test environments? Does committed code get bogged down in testing? You have to decide how important testing is to your overall goals.
Do you have to revise committed code too often because it won’t run in the production environment? You need to identify the bad things your tools do today, and either fix them or get new ones. If your tools are clumsy, people won’t use them. If they encourage people to do the wrong thing, then people will do the wrong thing.
The first step is to identify the workflow bottlenecks that prevent your organization from developing code more rapidly, and deploying it more frequently.
There are two main paths to identifying workflow bottlenecks. First: Just ask! Ask your team where things get bogged down as code advances through your development and production pipeline. Ask them to rate the severity of these bottlenecks, and identify the mission-critical ones. (If you’re doing Kanban, congratulations: You probably already have a good sense of your workflow bottlenecks.)
But the anecdotal approach isn’t enough. You also need to study your system logs. Learn which tasks and services are used the most and take the most time, which systems have the least availability, and so on. That will give you hard evidence of where your pipeline is working well, where it’s suboptimal, and where it’s failing. Just as important, you’ll have baseline data you can use to measure performance improvements moving forward—and pinpoint the parts of your pipeline that still need work. Combine the results of your anecdotal and data-based research to prioritize your tool needs.
Focus on core tool categories
Most successful DevOps organizations automate using tools in a few core categories, using a variety of specific tools:
Configuration management. WhenDevOps aficionados throw around phrases like “automated infrastructure,” “infrastructure as code,” and “programmable infrastructure,” they’re talking about configuration management. That’s the tracking and controlling of changes to the software code base and the archiving of all file versions into a central configuration management database (CMDB), which enables multiple developers to work on the same code base while avoiding version-control issues. Popular configuration management tools include Ansible, CFEngine, Chef, Puppet, RANCID, SaltStack, and Ubuntu Juju. But the real question is what do you need in configuration management? For example, if you want to take in data that other people provide and then do something with it, you need a tool that handles that well.
Application deployment. Application deployment tools enable the automation of releases, and are at the heart of continuous delivery, one of the primary tenets of DevOps. Capistrano, a deployment library, is the most popular standalone tool in this category. Other popular tools for automating application deployment include Ansible, Fabric, and Jenkins. Again, the key is to find a tool that tracks behavior—from history to change logs--in ways that is meaningful for both dev and ops.
Monitoring. DevOps requires two distinct types of monitoring. Application performance monitoring tools such as New Relic APM enable code-level identification and remediation of performance issues. At the infrastructure level, server monitoring tools like New Relic Server provide visibility into capacity, memory, and CPU consumption so reliability engineers can fix issues as soon as they appear. The key is make sure that everyone can see the data so they can make better decisions.
Version control. To achieve the benefits of DevOps, it’s essential to version not just your application code but your infrastructure, configurations, and databases. This requires scripting all of your source artifacts, but the payoff should be a single source of truth for both your application code and your IT systems and databases, allowing you to quickly identify where things went wrong, and recreate known states with the push of a button. No more having to play Sherlock Holmes to figure out which versions of your application code goes with which environments or databases. While commonly used version-control tools include Git, Perforce, and Subversion, they differ widely on how well they support DevOps-style collaboration.
Test and build systems. These tools automate common developer tasks including compiling source code into binary code, creating executables, running tests, and creating documentation. Tools in this category include Ant, Gradle, Jenkins, and Maven. Hosted services like Travis and BuildHive offer additional options.
The right tool chain for DevOps will automate IT services, provide real-time visibility into system and application performance, and give you a single source of truth. More important than an individual tool’s capabilities, though, is how closely the all match your organization’s strategic goals. That’s the way to maximize your chances of achieving DevOps goodness.
Of course, tools are only part of the DevOps equation. You also need to create a culture that gets dev and ops working together towards the same goals. To learn more about bringing dev and ops together, read 6 DevOps Best Practices: Bridging the Culture Gap.
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.