When you adopt a DevOps approach to building and operating software systems, you must rely on modern tools for almost every aspect of build, release, and operations activities. But before you get into the weeds of comparing one tool against another, you need to think more broadly about what you need.
And there are many types of DevOps tools to consider. With DevOps, many previously manual or semi-manual activities are fully automated, including version control (for application code, infrastructure code, and configuration), continuous integration (for application code and infrastructure code), artifact management (packages, container images, container applications), continuous delivery deployment pipelines, test automation (unit tests, component tests, integration tests, deployment tests, performance tests, security tests, etc.), environment automation and configuration, release management, log aggregation and search, metrics, monitoring, team communications (chat, video calling, screen sharing), and reporting.
You'll find plenty of excellent tools in all of these categories, but it's easy to get hung up on the pros and cons of using one tool versus another. And while sometimes that’s the right debate to have, confusion around tools may be a symptom of deeper problems with respect to the way in which your team uses those tools, or how you introduce those tools to the team.
I have been using the guidelines below with clients for about five years, and we’ve managed to solve tooling-related problems that would otherwise have descended into an unhelpful product X-versus-Y shooting match. To become a high-performing organization, you must take into account the social dynamics of your organization and the trajectory of the rapidly evolving public cloud vendors.
Choose tools that facilitate collaboration
Having highly effective collaboration between teams is critical for DevOps. Some people think they need to buy a dedicated collaboration tool for this purpose, but there are many different tools you can use to enhance collaboration.
Consider one of the cornerstones of a DevOps approach: version control. Let’s say you're trying to encourage more people in the organization to use version control, including for database scripts, configuration files, and so on. If you insist that everyone use only a command-line tool for version control, you'll miss out on collaboration opportunities:
Command-line tools can be a barrier to collaboration for some people.
The command-line view of version control is certainly part of a DevOps tool set, but it is unfamiliar to many people—especially non-developers—and has no obvious collaboration potential. But if you use a richly featured version-control platform such as Github, Bitbucket, or Gitlab, you can take advantage of discussion threads around file changes to get people talking about why a file changed. This helps you collaborate with people who have different skills, and encourages more people to learn how to use version control:
Browser-based tools can help to encourage collaboration for people who are less technology-savvy.
Using a browser-based version-control platform opens up version control to a wider audience than just software developers, which in turn helps you to emphasize the importance of version control as a key DevOps practice. By choosing a version-control tool with discussion capabilities and making it available to a wide audience, you can enable rich communication between teams and groups within your organization.
The same approach works for many other tools, too. I once consulted with an organization that had a tool for log aggregation and search. The IT operations people found it valuable, but the developers did not have permission to search the logs from the production systems. Access was denied because, IT claimed, the data was of a sensitive nature. But the managers wanted to improve the way in which the IT Ops and Dev teams collaborated. So they opened up access to the log-search tool for developers and—surprise— developers and operations people collaborated more. The tool hadn't changed, but changing access permissions enhanced collaboration.
Key points:
- Value collaboration as a key selection aspect of tools.
- Look behind the tool's main purpose to find collaboration opportunities.
- Ask, “How does our use of this tool help or hinder people in collaboration?”
Favor tools with APIs
Modern software development needs delivery tools that are highly automatable, yet customizable. That means you need a fully featured API for each tool—preferably one that's HTTP-based. When you compose capabilities by gluing together API-rich tools, you enable easy wiring for alerts and other events. Avoid tools that try to do everything from within their own frames of reference; favor those that do one or more jobs well and integrate easily with other tools.
Given the speed of change in the software sector, it’s particularly important to choose tools that meet these criteria. If you do, then when a new tool comes along you'll be able to replace your old tool with minimal disruption. Being stuck with a big, lumbering tool set that's only half-good at most things has been a source of significant pain for organizations trying to adopt DevOps. Keep your tooling nimble and composable to give your team the flexibility to adapt new approaches easily.
But beware of “spaghetti” tooling that's chained together with undocumented scripts. Treat your software delivery and operations tools like a proper production system. At the rapid pace enabled by DevOps, it’s essential to be able to keep the tools you use for software delivery and operations running and working 24x7. Many companies make the mistake of adopting new tools without the operational support and care needed to make those tools work well. So when adopting new tooling, consider starting with SaaS-hosted offerings and running internal prototypes/demo versions before building an internal capability.
Key points:
- Choose tools that expose APIs.
- Aim for composition of new capabilities from multiple API-driven tools.
- Build and deployment are first-class concerns.
Favor tools that can store configuration in version control
One core tenet of DevOps is that you should store all configuration settings in version control. That includes the configuration not just for your custom software applications, but also for tools you use in software delivery and IT operations.
To be effective in a DevOps context, each tool must expose its configuration in such a way that you can store the configuration as text files that you can then expose to version control. Then you can track the history of configuration changes and test changes beforehand.
Why would you want to do that? If you cannot track and test configuration changes to your delivery and operations tooling, you risk breaking the machinery that makes DevOps work.
Key points:
- Choose tools that expose configuration to version control.
- Point-and-click is no longer acceptable for configuration of tools.
Use your tools in a way that encourages learning
Some of the tools useful for DevOps are quite involved and complicated, especially for people new to them; don't expect everyone to understand or adopt difficult new tools immediately. In fact, if you introduce a tool that is too tricky, some people may become hostile, especially if you don't provide training or coaching. That sometimes happens when organizations select best-of-breed tools without considering how easy they are to use.
Assess the skills in your organization and devise a tools roadmap for moving teams to improved ways of working. Select tools that offer more than one way to use them (GUI, API, command-line) so people can learn at their own pace. And avoid leaving people behind on the climb to more advanced approaches by holding regular team show-and-tell sessions to demonstrate tools and techniques.
For example, you might start with the browser-based interface, such as the one below, for people new to version control, giving them time to adjust to this approach before training them on the command-line tools for version control.
Command-line tools can be daunting for some people and may hinder collaboration unless you provide training. Tools with a more friendly UI can help to bring people on board to new ways of working, giving them the confidence to adopt command-line tools later.
DevOps is a journey from mostly manual to fully automated, and not everyone starts from the same place. Give people time and space to become familiar with new tools and approaches. They might start with a simpler tool, then adopt a more powerful one later.
Key points:
- Bring people with you on your DevOps journey.
- Prefer achievable gains now over possible future state.
- Avoid a fear of too-scary tools by stepwise evolution.
Avoid special production-only tools
The speed and frequency of change that DevOps gives you the means you need to emphasize the feedback loops within your delivery and operations processes. In particular, it is important that all technology people in your organization learn as much as possible about how the production environment works so they can build better-working, more resilient software. You also need to test changes to all parts of the software system before deploying new versions to production.
Production-only tools prevent teams from learning because production is treated as a special case.
For an effective DevOps approach, choose tools that work easily in nonproduction environments (development, continuous integration, staging, etc.). The tool should be cheap enough to buy or install so that you can install it in all environments, including developer laptops and the automated build-and-test system. A tool that is so expensive that you can only afford a license for production is not a good tool for DevOps. Such "singleton" tools tend to accrue an aura of magic, leading people to think that production is special. People become disengaged, and that's a bad outcome. Good tools for DevOps are also easy to spin up in different environments using automated scripts. A tool that needs manual installation is not a good choice for DevOps.
Running the same tools in production as in all other environments enables rapid learning and increases engagement within teams.
In some sense, this “run it anywhere” approach to tools for DevOps makes production less special, and rightly so. Many of the problems with older, fragile IT systems are the result of production being treated in a special way, preventing developers and testers from learning how production works. With a DevOps approach, your aim is to choose tools that are easy to install and can spin up in multiple environments, even if the feature set is less impressive than that of a tool that is more advanced but difficult to configure. Aim to optimize globally across teams that need to collaborate, not just locally for production.
Key points: Production-only tools ...
- Break the learning feedback loop.
- Make CI/CD more difficult.
- Underestimate the value of collaboration and learning.
Choose tools that enhance inter-team communications
One of the most common problems I see in organizations struggling to build and run modern software systems in a DevOps way is a mismatch between the responsibility boundaries for teams or departments and those for tools. The organization either has multiple tools when a single tool would suffice (in order to provide a common, shared view), or it has a single tool that's causing problems because teams need separate ones.
In recent years, Conway’s Law has been observed and measured in many studies. The communication paths in our organization drive the resulting system architecture:
“Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.”
– Mel Conway
You therefore need to be mindful of the effect of shared tools on the way in which teams interact. If you want your teams to collaborate, then shared tools make sense. But if you need a clear responsibility boundary between teams, separate tools may be best. Use my DevOps team topologies patterns to understand which DevOps model is right for your organization, and then choose the tools that fit that model.
If you need the development team to work closely with operations (the Type 1 model), then having separate ticketing or incident management tools for Dev and Ops will result in poor inter-team communication. To help these teams collaborate and communicate, choose a tool that can meet the needs of both groups. But be sure that you understand the user experience needs of each group, since a tool that infuriates your engineers is a sure way to stop a DevOps effort dead in its tracks.
In a Type 1 platform model, smooth collaboration implies some shared tooling between Dev and Ops.
If, like many enterprises, yours is moving to a Type 3 (platform) model, then the platform team is not responsible for the live service of the applications; that's the responsibility of the product development teams. When responsibility boundaries don't overlap, you won't get much value from insisting on the same incident-tracking tool or even the same monitoring tool for the platform and development teams. This becomes even clearer when IT operations has outsourced to a cloud service provider, since in that case there's no question about forcing the same tools on two different teams.
A Type 3, IT Ops as infrastructure-as-a-service (platform) implies little need for shared tooling between Dev and Ops.
In summary, don't select a single tool for the whole organization without considering team inter-relationships first.
Key points:
- See the whole organization as a system you're building.
- Have separate tools for separate teams.
- Deploy shared tools for collaborative teams.
Optimize for learning, collaboration, automation, and team dynamics
When choosing tools for DevOps, it’s important to avoid product X-versus-Y tooling shootouts that simply compare lists of features side by side. Sometimes that’s needed, but only after you understand the broader implications of having one (or both) of those tools in place in your organization. Using tools in the wrong way—especially trying to make everyone use the same tool—can be counterproductive for DevOps.
Try to assess and understand where your team communication boundaries should be, using the DevOps team topologies patterns and Conway’s Law, to avoid a one-size-fits-all approach to tools. Sometimes, using multiple, similar tools is the right approach, but that depends on your team boundaries.
Ensure that the tools you choose do not present a learning barrier to people who are new to DevOps approaches; expect to replace tools regularly as people develop their skills and establish new collaboration patterns.
Tools for DevOps need programmable APIs. Don’t buy or use tools that need a human operator to click buttons on a browser application. With DevOps, you need to compose functionality from multiple, cooperating tools using APIs and “glue” scripts.
Finally, don’t optimize for your production environment. A tool that exists only in the live production environment is a tool that you can't test upstream, and that’s a dangerous approach in a fast-paced DevOps world.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
