This past Christmas, my wife Sarah was kind enough to buy me what my heart truly desires – more tools. In this case, it was 20V DeWalt tools, including a drill and driver set. Of course I was delighted, but then, I saw which drill it was and my heart sank. I had the very difficult job of telling Sarah I wanted to take the drill and driver set back to the store and get different ones. It was difficult to break it to her that the drill in the set wasn’t quite the tool I wanted.

The DeWalt drill that went on sale on Black Friday didn’t have a “hammer drill” setting. Hammer drills are critical for drilling into masonry. Being that our home is concrete block, that tiny feature on what is otherwise a perfectly good drill is the difference between an enjoyable few minutes making a few holes and a frustrating three hours asking myself what I’ve done to spite the universe.

This experience reminded me that which tools we choose to use can be a very important decision. One or two features can make all the difference.

In DevOps, tools are one of the three things that encompass how we deliver value: Tools, People, and Processes. I’ve heard it said that an undue amount of attention has been lavished on the tools. Maybe. However, that doesn’t mean we can start ignoring the importance of tools.

A man is only as good as his tools. – Emmert Wolf

Probably women, too, but what does Emmert know.

If I asked someone to write a modern web app by hand-writing assembly or delving into IBM punchcards, we’d be waiting a long time. In software development, I’ve found discussions around editors or stacks to be natural and ever-evolving. I constantly experiment to find out what works well for me. Is log4net better, or Serilog? Is Visual Studio still the hotness, or should I try out Project Rider?

I’ve found that I view these things as modular, replaceable. I can move from Visual Studio to Project Rider at any time to just try it out, and then jump back into the warm, inviting waters of Visual Studio again if we don’t like it. I’ve found that this constant experimentation with different variables of what tools I use has made me a better, faster, stronger developer over time.

And yet, I’ve seen a lot of trepidation when it comes to experimentation with DevOps tools themselves. The whole idea of DevOps is to improve how we deliver value. Deliver value faster, easier, and more consistently. Experimenting with the software being delivered is second nature. Of course I want to make features for my software, deliver them, understand how they are being used, and then update my application with that knowledge. But what about the tools around DevOps themselves?

You can’t buy DevOps and install it. – Donovan Brown

You certainly cannot, Donovan. I understand the frustration with people who think you can do that. To be brutally honest, it’s usually managers that have heard of DevOps and the benefits, and aren’t sure what it means quite yet, so they want to buy a tool to do it. Or, they want to hire a DevOps Engineer to take care of it.

However, once that manager reads The Phoenix Project and Accelerate about DevOps culture, then they may be asking themselves what tools to put into place to make it all work.

At New Signature, we’ve found some great tools to help us deliver better software, faster:

  • Microsoft Azure Pipelines
    • All your continuous integration and delivery needs in one place
  • Microsoft Azure Boards
    • Organizing work made simple
  • Microsoft Azure Repos
    • Version control with a great user experience
  • RedGate Toolbelt
    • DevOps for your SQL databases
  • xUnit & MSTest
    • Automated unit testing is the first line of defense against errors
  • Powershell
    • A powerful scripting language for automating things that otherwise would be difficult to automate
  • Microsoft Visual Studio 2017
    • A powerful IDE
  • Microsoft Visual Studio Code
    • A lightweight code editor
  • Microsoft Application Insights
    • Easy-to-set-up logging for both server and client-side events in web applications
  • Microsoft Power BI
    • Visualize data from anywhere

This is far from an exhaustive list, and we continue to experiment. Right now we’re working with containers via Kubernetes to see if that can help encapsulate software and their dependencies to make it easier to deploy to the cloud. Like I said, we’re never done.

If you are at the very beginning of your DevOps journey and are looking to start using some tools, we can recommend taking on a technology or two from the above list (I’d start with Azure Repos and Pipelines) to start making your life easier. If you feel like your DevOps tools are a jumbled mess of stuff that doesn’t work well together, definitely take a look at the above tools as well. Tools are supposed to help the process, not get in the way. If it feels like they are getting in the way, it’s better to not succumb to the sunk-cost fallacy and make a change sooner rather than later. And if you’d like some help implementing these sorts of tools, that’s just the sort of thing we do.

We are taking our DevOps expertise on the road! Check out our listing of free in-person DevOps workshops to join in on a guided DevOps learning experience.