The DevOps Toolchain per Ravi Gadhia, GitHub

Thanks to Anders Wallgren, CTO and Sam Fell, V.P. of Marketing at Electric Cloud for hosting and moderating our roundtable discussion on the necessary elements of a healthy DevOps toolchain with Ravi Gadhia , Solutions Engineer at GitHub , Lee Atchison, Senior Director for Cloud at New Relic , Ian Buchanan, Principal Solutions Engineer for DevOps at Atlassian , Mark Miller, Senior Storyteller and DevOps Evangelist at Sonatype , Prashant Mohan, Product Manager at SmartBear, and yours truly.

You can see the full podcast here .

Following are Ravi’s thoughts on the four topics we covered:

The DevOps Toolchain as a Value Stream

What I have observed is that many enterprises will have this. They want to enable their developers to choose the custom toolchain of their choice, and they end up having this sprawl along tools where there's no standardization, everyone is sort of doing their own thing, it's the Wild West, then it's very difficult to manage and apply governance across your entire toolchain.

I think going through this exercise helps companies recognize that, "Hey, we don't have a standard approach, we have no way of kind of measuring our lead time because we're doing it in so many different ways." And so what I see happening as a natural follow-on for that is that enterprises are looking at greenfield and high-value brownfield as areas where they will try to standardize toolchains, so they have templates they can apply for different types of applications.

Using Tools to Align People and Teams

I think you could definitely think of GitHub as historically being on the creation side where we started off as Git with a GUI slapped on, we moved into more software collaboration with branches and pull requests.

We have some features squarely in the planning area with project boards and issues. But really, we think GitHub is really emerging into a platform where developers can go integrate with their tools downstream, as they wish to, and then using a rich API for reporting status back, they can actually get a view of a lot of this flow straight from GitHub, from the pull request or from whatever repo that they're looking at.

So, we see ourselves as pretty integral to enabling this type of flow in a very, successful way. One of the things we did last year was release GitHub Marketplace. It's like a one-stop shop for developers to select integrations, configure them on-the-fly, with integrated billing as well. We’re trying to make it really easy for people to just select, wire-up their toolchain out of the box. So code is not just application code anymore. We have infrastructure as code, we have docs as code. All of these require their own custom toolchain downstream.

Is There One Right Tool?

I agree with the cliché, "pick the right tool for the right job," but I think it's important to recognize the right tool might change and probably will change because the industry is changing. If you're going to be a friendly player in the space, make your tool easy to reconfigure or pull out.

Tools should not lock in users. It should be easy to, or low friction to, reconfigure a toolchain for a different tool as the right tool will change. We don't want our customers to have to rip and replace. But often you need to make changes to really get the best out of what's out there and what's available. This is something that people should be open to.

Adapting to the Changing Environment

In addition to ease of integration, I think other qualities that would characterize healthy tools or friendly players in the toolchain, would be like accessibility to data, like both the internal performance data of how the system is running, but also migratability of the data. If you want to move off of one source code management system to another, that should be relatively easy. And the other things I see my customers often needing are auditability and traceability.