Measuring Your DevOps Maturity

Measuring Your DevOps Maturity • Incorporating DevOps into your organization is not a zero-sum game. It is a journey. And like most journeys, it can be measured. • When measuring your DevOps journey, you need to show progress as well as setbacks. Additionally, it’s critical that you make sure these measurements are accurate, automated, and visible—just like your DevOps. • So when it comes to measuring, where do we start? First, let’s make sure we’re all talking about the same thing.

What Is DevOps? • When many people think about DevOps, they narrow the definition down to an application build pipeline. Whatever makes the code get from the developer’s IDE out to production in an automated fashion is their DevOps. But there’s more to it than that. • DevOps involves not just the applications, but also infrastructure, data, and your enterprise itself. It’s not just about the automation and monitoring of those aspects, but building the culture of DevOps around core values. • Given this definition, how do you measure where you are in your DevOps journey? How Mature Is Your DevOps? • Source: Enov8’s “100% Agile within a Year – The DevOps Cube” • Now that we’ve defined DevOps, we’re going to take a look at how to measure DevOps maturity. We’re going to pull some concepts from Enov8’s DevOps Maturity Block, as well as additional things that can help you figure out where you are on the journey.

First, the DevOps Maturity Block identifies where you are with the build, deploy, and test stages of your application for your application, data, and infrastructure. By identifying where each of these segments are in the journey, you can see at a glance what areas you should focus on.

And the stages can be separated into six sections: • Chaos: There is no automation, or hacked-together, un-monitored scripts run loose on your environments. Each team does their own thing. • Manual: There are steps, but most include manual intervention. Whether it’s running a script or manually moving files around, your people are the process. • Hybrid: Here we’re starting to get some good automation and monitoring in place. • One–Command: This can be seen as the easy button. This could mean that deploys require someone to approve or push a button. • Self–Service: Applications, data, and infrastructure are self-service. If a team needs a new integration environment, they’re able to provision it themselves without much difficulty.

DevOps Maturity for Applications • The longer applications sit in a development or testing environment, the harder deploying to production will be. Requiring more manual steps increases the chances of human error. • When you add uncertainty and points of failure, you add to the chance of something going wrong. This isn’t the fault of bad programmers or individual screw ups; this is probability. • The ease with which you can move code safely from development to production indicates how mature your DevOps is. So how do you measure your application’s maturity? • Well, how many of the following practices do you have as automated components of your deployment pipeline? • Builds kick off automatically based on a commit push or a pull request. • Tests run automatically at all levels: unit, acceptance, contract, and canary. • Automated code coverage and code linters measure and report on your code trends.

4. Security scans search your code and dependencies for vulnerabilities. 5. Monitoring is in place, ensuring that your application is up and running. Proper health checks and error reporting provide quick feedback when things go wrong. • Then once you have the proper automation in place, keep an eye out for DevOps deployment smells like different scripts for different environments or waiting for slow times to deploy. Don’t let bad habits like that take away from your progress. DevOps Maturity for Infrastructure • Have any of you worked in an environment where it took months to get virtual machines set up for a new project? Or perhaps one where changes to infrastructure were all done manually, making them prone to error? • Or worse, have you seen changes to infrastructure that brought everything to a crashing halt but that couldn’t be simply undone because teams were creating all this infrastructure by hand?

DevOps can fix this, giving you confidence and repeatability where often there’s been none. • For infrastructure, look at capabilities around automating, streamlining, and allowing self-service for: • Provisioning environments. • Vertical and horizontal scaling. • Migrating between hosts, servers, or even cloud providers. • Deploying to multi-cloud environments. • Rebuilding infrastructure weekly or even nightly. DevOps Maturity for Data I’ve seen many companies and corporations that like to skip the data side of DevOps. “It’s too difficult. Data has state! You can’t automate that,” they lament. “We need stricter controls. We have to have the DBAs verify good design!” they cry.

But what really happens? The data architects fill out forms and diagrams. They throw requests for new tables and columns back at the developers because the requests didn’t meet some incomprehensible and ever-changing naming standard. • The DBAs wait for tickets and requests. Then they mindlessly execute those changes without much thought as to what the consequences are. And deployments fall behind because someone somewhere is waiting on a request fulfillment from the database team. • Oh, and they’d better have that request executed at exactly the right time, or the application will break! • You may suspect that DevOps can help improve this as well. You’d be correct. • DevOps for data, or DataOps, has been a growing field of opportunity. The idea here is to find ways to automate changes to the data and validate functionality on a regular and automated basis.

DevOps Maturity for Enterprise • Now what’s often missed in the understanding of DevOps? The effect DevOps creates in the enterprise as a whole. • Good DevOps gives an overarching end-to-end view of not just one system, but all the systems currently running. DevOps cannot solve all your problems if you do not take a holistic view. • As mentioned before, our measurements should be automated. But how do we automate something that traditionally took the form of a hand-crafted Excel report or a PowerPoint? • Fortunately, Enov8 has you covered with its ecosystem dashboards. These dashboards provide that holistic view you’ve been missing. They will quickly show you how well you’ve progressed on your DevOps journey.

What’s the Harm in Not Measuring and Improving DevOps? • You’ve been doing things the same way for years, if not decades. Sure, it takes longer to get things to production than it used to, but that’s just a natural part of growing a system. Right? • Perhaps not. Here are the two biggest risks that come with not checking in on your DevOps. Overcompensating with Manual Processes • One thing that often goes wrong in enterprise is that mistakes and misses are replaced with additional red tape. This red tape slows down the release of new features and changes. It ensures quality by making everyone jump through 30 burning hoops. • Why’s this bad, you ask? If we ever meet and have time for a chat, ask me about the horrors of filling out Excel forms to request a deployment from one environment to another. And listen carefully when I tell you about additional weird requirements.

These requirements push you to specify each changed file and version that gets deployed together. Consider the paperwork involved when one of those program files needs a small update that’s found in the two-week testing window. • Prepare for me to blow your mind about processes created simply to make the system feel “safer.” Why do things like this happen? • Because processes like this come out of good intentions. Someone noticed a flaw or bug that made it to production. Then instead of automating a solution to fix the problem, additional manual checks were added with the intention of making sure the mistake never happened again. • Unfortunately, all this did was slow down development to a crawl and add frustration to everyone’s lives. You’ve only added the illusion of safety. So what else is there?

The Friday Afternoon Fear Factor • Does the idea of deploying something to production on a Friday afternoon fill you with fear? Do you have a sense of dread coming over you when you think about all the potential disasters that could be lurking and jumping out at your customers all weekend long? • Know that this fear is good. It is normal. But what you want to do next is identify where the truth lies beyond that fear. And then you can address it. • Though if that sounds a bit too much like your last meditation session, let’s make it more concrete. What automation and safeguards will give you the confidence to not worry over each production deploy? • Start listing them out. What are the things that you or your team does manually after every deploy to production? Does your deployment process include manual checking, double checking and gaining sign off of every step? Congrats, you just found some great places to start your DevOps maturity journey!

Where Do We Go From Here? • As we all know, just because we say we have a culture of DevOps doesn’t make it true. Adding in random points of automation here and there won’t give you the big picture sense that you’re on the right track. • To truly realize the benefits of DevOps, you must take a good hard look at where you’re at and then make the necessary changes to move your organization in the right direction.

Contact Us Company Name : Enov8 Contact Person : Ashley Hosking Address : Level 5, 14 Martin Place, Sydney, 2000, New South Wales, Australia. Phone(s) : +61 2 8916 6391 Fax : +61 2 9437 4214 Website :- https://www.enov8.com

Thank You

Measuring Your DevOps Maturity