Key Takeaways from Continuous Discussions(#c9d9) Episode 89: The DevOps Toolchain
In a recent episode of the Continuous Discussions (#c9d9) podcast, we partnered with DZoneto host a panel of industry experts to discuss all aspects of the DevOps toolchain — from value streams to teams and architectures.
The panel included: Prashant Mohan, product manager at SmartBear; Lee Atchison, senior director of strategic architecture at New Relic; Ian Buchanan, developer advocate at Atlassian; Tom Smith, research analyst and strategist at DZone; Mark Miller, DevOps evangelist at Sonatype; Ravi Gadhia, senior solutions engineer at GitHub; and Electric Cloud’s Sam Fell and Anders Wallgren.
Continue reading for some of their top takeaways!
The Toolchain as a Value Stream
Mohan advises to look at the bigger picture when it comes to quality throughout the value stream: “As far as quality is concerned, it’s something that we have to look at from a very broad perspective, not siloed. I talk with customers every day regarding little, small parts of issues that they have. But if we take that a step back and talk to about two or three people in that same value chain, you find that the problem is much bigger, and that people generally don’t understand that.”
Atchison encourages us to look at the bigger picture: “I can’t express enough the value of having a single set of integrated tools that shows you a broad picture across the entire spectrum of the process. There is so much that can be learned from one side of the process by knowing how the other side of the process is working.”
Focus on decreasing non-value adding time in your value stream, says Buchanan: “A lot of developers tend to look where the light is shining. Where their automation shows them, ‘Hey, the test took two hours.’ And they shrink that down to ‘Oh, let’s see if we can get that to an hour,’ but they’re missing the time in between, the non-value adding times.”
Integration is key with today’s volume of tools, per Smith: “I hear people talking about the explosion of tools and the need for all of those tools to be able to integrate with one another, because developers do want to use what they want to use. You can’t be exclusive, you’ve got to be able to work with everything.”
While letting developers pick the tools they want, across an enterprise this can cause some serious issues in terms of standardization and compliance, says Gadhia: “Many enterprises want to enable their developers to choose the tools they want, but they end up having this sprawl of tools where there’s no standardization. Everyone is doing their own thing, it’s the Wild West, and it’s very difficult to manage and apply governance across your entire toolchain.”
In reference to the above image, Miller explains: “We’ve found that people are searching for these types of diagrams to find out, number one is, is what I do in alignment with what other people are doing? The other one is how do I get started? And if you can give me a picture about how other people are doing it then it gives me an idea on how I can get started.”
To conceptualize the value stream, think about how a piece of code travels through it, describes Wallgren: “Think about the value stream from the code’s perspective. Is the code sitting there in the dark, lonely, all by itself waiting for you to help it, fix it, make it better? Or are you always touching it and adding value to it?”
Value streams allow for optimal collaboration and can be truly eye-opening especially to those still functioning in silos, per Fell: “As part of the value stream, there are different parts of the process where you have people who are very attuned to a certain part of that process that have no idea what’s upstream or downstream. When our customers go through this process, they bring all these folks into the room and it’s just amazing. Their eyes open wide and they go, ‘I didn’t realize that we were doing that downstream. I’ve already done that upstream and so why are we doing it again?’”
Using Tools to Align People and Teams
Mohan emphasizes the importance of verification in every step of the toolchain: “Whatever verification you do it has to be informed and influenced by what your customer is doing. It’s not about achieving 90% automation, it’s about automating the functionality that 90% of the customers use.”
Monitoring helps with collaboration throughout the entire software delivery process, says Atchison: “Monitoring gives everyone in the organization the visibility they need to understand what’s going on everywhere. And by giving everyone the same level of visibility, it makes decisions more uniform, makes problems easier and quicker to find, and therefore, making the resolution of those problems and the cycle time through this whole loop much, much faster.”
To improve efficiency of monitoring feedback loops, Buchanan provides this suggestion: “Batch size has to shrink. Otherwise, all that happens is as monitoring feedback-data-points come in, they just pile up in a backlog, and you can’t act on them if you have a plan that’s spanning out for the next year.”
Visibility can help tear down silos, according to Smith: “I think visibility from all the tools is tremendous in helping tear down the silos and promote collaboration which we know is critical to the success of DevOps.”
We’re living in an “everything-is-code” world, explains Gadhia: “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.”
Words of wisdom on security from Miller: “A lot of people when they first start don’t realize just because you put something secure into the application doesn’t mean it’s going to remain secure for the duration of that application.”
Simple advice from Wallgren: “If you’re not worrying about your biggest constraint, chances are you might be doing local optimizations that are not really going to move the ball for you.”
Fell reminds us that we’re all in this together: “One of the things that I love about the DevOps community is that there are a lot of frenemies, there is a lot of coopetition. But ultimately, what we want is a marketplace where everybody can compete on equal footing and where we’re all trying to help drive the progress of the software delivery methodology. Can you imagine the kind of technology that we have today, and by working together how we can make that even better for our kids and our grandkids?”
