A Practical DevOps Resource to Help You Standardize Your Toolkit
The simplest tools are often the most effective, and this one gives you a visualization for the compatibility of your tools.
Join the DZone community and get the full member experience.Join For Free
When I started the State of DevOps survey over seven years ago, the landscape looked very different than it does today. The organizations we were working with were struggling with deployments, the functional boundary where Dev and Ops painfully collide. The pressure to deploy faster and more frequently was a big driver behind DevOps.
As more organizations started adopting DevOps and practices became codified and broadly shared, we saw the low performers start to catch up with the high performers when it came to deployment frequency; a good sign that this was a solved problem. But of course, deploying faster and more frequently doesn’t necessarily mean you’re deploying better. And on the flip side, many organizations we work with today actually can deploy much faster and more frequently than the business allows.
Last year, we broke new ground with our report by focusing on the DevOps journey itself. We wanted to answer two burning questions that we kept getting asked over and over again: “How do we get started with DevOps?” and “How do we expand our pockets of success?” From those core questions — and a lot of statistical analysis — emerged the DevOps Evolutionary model (or simply, the DevOps Model, as it’s more commonly known). The model deepened our understanding of how organizations adopt and scale DevOps practices. From there, we set out to provide prescriptive and pragmatic guidance, based on the real-world experience of our authors (both in the trenches and from working directly with IT organizations), to help organizations evolve on their journey.
The Importance of Normalization and Standardization
In the 2018 State of DevOps Report, our analysis revealed five stages of DevOps evolution and the critical practices at each stage that help you achieve success and progress to the next phase of your journey. The first two stages of that journey are normalizing the technology stack and standardizing and reducing variability. Normalization is about getting your arms around the chaos and understanding what you have so you can eliminate the one-offs that create management complexity. Standardization is about placing bets on the technologies you’ll use in the future.
Nigel and I have been meeting with and conducting DevOps Workshops with very large, very complicated enterprises and the majority of them are stuck somewhere in between Stage 1 and Stage 2. Standardization is always a sticky topic because everyone recognizes the value of standardization, but often, no one person in the organization really has the power to enforce the standards. And then there are always those pesky dev teams that want to use their own special stack. We advise starting small with the tools and platforms within your direct purview before attempting to standardize your entire software delivery toolchain across hundreds of teams.
A Free Resource to Help You Standardize
To help you do that, we’re offering a new resource to help rationalize and standardize your toolkit. It’s a simple spreadsheet that lists key capabilities so you can see where there are overlaps between the tools you’re using today.
You can access the spreadsheet here, and then either make a copy of the Google sheet (File < Make a copy) or download it into a Microsoft Excel file (File > Download as). Then it’s all yours to fill in the tools you use, mark what their capabilities are, and note the overlaps where there may be opportunity for standardization.
A lot of our customers have found this to be useful so we wanted to make it available to everyone. This one happens to focus on infrastructure automation, but we plan to build out more resources in the future and would love to hear your ideas on what would be most useful. Feel free to email us at email@example.com with your ideas!
Published at DZone with permission of Alanna Brown, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.