How to Evaluate Which DevOps Tools You Should Add to Your Toolchain

At Trupanion, engineers consider vendor support, internal employee experience, and integration abilities.
Written by Michael Hines
May 12, 2021Updated: May 12, 2021
The Trupanion IT team
TRUPANION.

It’s almost hard to believe that the term “DevOps” was only coined in 2009. In the 12 years since, the field has exploded, with seemingly every tech company either fielding a DevOps team or working toward establishing one. This shift has naturally led to the proliferation of companies that design continuous integration, monitoring and infrastructure automation tools, among many others. Googling “top DevOps tools” returns lists ranging from 10 items to 52, which begs the question: Just what DevOps tools should teams be using?

This isn’t as straightforward a question as it sounds, at least not according to Sean Hampton, a DevOps engineer at Trupanion, a pet medical insurance company. For Hampton and his team, there are a handful of factors to consider when selecting new tools for their DevOps toolchain. For example, Trupanion leverages Azure DevOps, so ideally any new tool they incorporate into their toolchain would play nicely with Microsoft’s services. Those are table stakes, though. 
 

Inusrtech Has Gone to the Dogs (and Cats)Build Tech for Pet Owners at Trupanion


Given the plethora of options available, it’d be easy for teams to select software based on capabilities and pricing alone. Those are both factors Trupanion considers when adding new solutions to its DevOps toolchain. The company also evaluates the quality of the business it’s buying from.

“Solid rapport early on can usually inform how a long-term working relationship is going to go,” Hampton told Built In Seattle. “Establishing SLAs [service-level agreements] and understanding what training opportunities are offered early is important to make sure we know that once the application goes live, our team is ready.”


 

Sean Hampton
DevOps Engineer • Trupanion

Give us a brief glimpse into your DevOps toolchain. What are a few of your favorite tools your team is currently using?

We’re heavily invested in the Microsoft stack, and the biggest tool in our kit is Azure DevOps Services. We use ADO to leverage Azure Boards for work item management, Git in Azure Repos, Azure Pipelines to manage builds and some releases, and Azure Artifacts to store and manage build artifacts. We also use Octopus Deploy to automate the majority of our code deployments to VMs currently. The newest addition to our toolkit, and quickly becoming one of my favorites, is Terraform Cloud for Business. We will use this to manage the provisioning of new Azure infrastructure. 

All these tools work in concert to manage the build and deploy processes at Trupanion. As developers make changes to the codebase via feature branch pull requests, Azure Pipelines is monitoring those repositories for new code commits. An automated build will be triggered, which produces artifacts that will be added to our Artifact repositories and, depending on the application, will inform Azure Pipelines and Octopus Deploy that a new package is ready to be deployed.

We don’t want to force applications into roles they’re not meant to fill.”


What were some of the key considerations when evaluating and choosing the tools your team would use?

First, we consider if this is the right tool for the job that we’re trying to do. There are plenty of options for DevOps tools out there now, but it’s often best that we consider a purpose-built solution. We don’t want to force applications into roles they’re not meant to fill since it can sometimes cause headaches when things don’t go as planned. It’s also important to look at the tools we actively use and whether or not the new one will integrate. Our preference is that applications integrate with Microsoft Azure DevOps when possible, since it’s effectively the backbone of our DevOps toolchain. 

There’s also the matter of support from the vendor, as solid rapport early on can usually inform how a long-term working relationship is going to go. We’ve also evaluated tools based on the experience of team members. Having folks in-house give positive feedback on a tool we’re considering or a vendor that we’re forming a partnership with helps guide those decisions. Establishing SLAs and understanding what training opportunities are offered early is important to make sure we know that once the application goes live, our team is ready and we’re covered regarding any unforeseen issues.

 

How has your DevOps toolchain evolved over time, and why? 

We often evaluate new tools to help support the ever-evolving needs of the IT organization at Trupanion. As we’ve migrated toward more cloud-based infrastructure, we’ve had to identify whether the self-hosted solutions of our toolchain would be as effective as a comparable SaaS solution. Migrating from a server installation of Azure DevOps to the Microsoft-hosted services was a major effort and one that has turned out to be a net positive for us. 

We’ve replaced an on-premises artifact repository with the Azure Artifacts solution provided by Azure DevOps due to the upgrade path of the previous application being incompatible with the rest of our refreshed toolchain. Much of the evolution of our toolset has been in parallel with our migration away from self-hosted infrastructure and into the cloud. This will continue to expand to additional aspects of our toolchain as we grow our IT presence in the cloud.

Jobs at Trupanion

Seattle startup guides

LOCAL GUIDE
Best Companies to Work for in Seattle
LOCAL GUIDE
Coolest Tech Offices in Seattle
LOCAL GUIDE
Best Benefits at Seattle Tech Companies
LOCAL GUIDE
Women in Seattle Tech