The DevOps Toolchain per Prashant Mohan, SmartBear
The DevOps Toolchain per Prashant Mohan, SmartBear
In our DevOps toolchain podcast, Prashant Mohan stated that verification across the toolchain is critical. Read on to get more insights from the podcast.
Join the DZone community and get the full member experience.Join For Free
Easily enforce open source policies in real time and reduce MTTRs from six weeks to six seconds with the Sonatype Nexus Platform. See for yourself - Free Vulnerability Scanner.
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 Prashant Mohan, Product Manager at SmartBear, Lee Atchison, Senior Director for Cloud Architecture at New Relic, Ian Buchanan, Principal Solutions Engineer for DevOps at Atlassian, Ravi Gadhia, Solutions Engineer at GitHub, Mark Miller, Senior Storyteller and DevOps Evangelist at Sonatype, and yours truly.
You can see the full podcast here.
Following are Prashant’s thoughts on the four topics we covered:
The DevOps Toolchain as a Value Stream
We must ensure quality throughout the toolchain. It's something that we have to look at from a very broad perspective, not siloed. It's just so important to look at everything. I talk with customers every day regarding little, small parts of the issues that they have. But if we take that a step back and just talk to two or three people in that same value chain, you find that the problem is much bigger and that people generally don't get the entire scope of the problem.
So it is a cultural shift, it's a change in mindset. I think it's a lot of influencing people to change the way that they've been traditionally working. And I think it's always a challenge, but I think it's critical to always look at the bigger picture.
Using Tools to Align People and Teams
I think one thing to look at before we deep dive, you know, into what SmartBear offers and some of the tools that help in that verify stage is that while verify fits logically in this chain here with how to plan, and then create, and then you verify, I think it's important to understand that you have to verify in every stage of the cycle. I think you've got to verify your plan, you've got to verify what you create during the creation phase itself. That's something a lot of our customers are moving towards like we call it, the shift left movement, as we move left into the stream. And I think that's really important.
That's a trend that's catching on, and a lot of the customers we speak to, they're like, "Hey, we've adopted DevOps." And then we ask them, "Okay, what does that mean? Have you verified your DevOps chain itself?" And you know, there's been a lot of holes found and things don't align as well as they thought.
So, some of the key tooling that helps in the verify stage is one of the key aspects of service virtualization. So, very early on in your cycle is your APIs are not ready, so you want to virtualize them and have them test ready before you even have the application up and going. So that's one flavor of shifting left. SmartBear offers 14 different tools.
With the verify stage itself, you think about the testing, the automation pyramid, you're talking about UI and API tests. And so, one of the big open-source products that we have, Soap UI, I think is critical because it's used by developers as well as your QA folks so that the collaboration happens very well once they start using the same tools. And then finally, you want to test your UI because that's what your customer eventually, sees.
So the critical point here is that 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. I think that's critical. And then so verify across the chain is critical.
Is There One Right Tool?
There's not one right tool, but there aren't 100 right tools either. It's important to find that sweet spot of how many different tools you need that speak to each other. And if you can get set up quickly, and you can get results quickly. So I think that's important. So no one vendor and no one right tool, but not a hundred right tools either.
It's important to get the organization on board there because different people will want to try different things but it's important to sort of nail down, "What problem am I trying to solve," and use DevOps as a journey towards the final outcome rather than DevOps as the outcome itself.
Adapting to a Changing Environment
Product consumption is important. Your product should be able to be consumed by the whole toolchain and your product should be able to consume other tools as well. It comes back to those integration capabilities to and from APIs. Work together and make sure that at the end of the day, you’re able to give your customer something that they value.
A lot of times we try to focus on delivering quickly, being lean, and things like that. And often we forget about verifying the entire system and making sure you're looking at it from a top-down perspective that, "Hey, you know what, things are actually working fine." And you might have the best deployment, you might have the best code written, you might have the best automation tests, but if your website crashes on ‘Prime Day’, then you have not done a good job.
Opinions expressed by DZone contributors are their own.