You are here

DevOps by any other name is still DevOps—unless you're not doing it right. Here are nine ways to tell if you're truly doing DevOps.

9 ways to tell if you're really a DevOps organization

public://pictures/studiobooth_day2_session2_0208_-_techbeacon_0.jpg
Malcolm Isaacs, Senior Researcher, Micro Focus

Many people believe that their organizations use a DevOps approach, but the "best practices" they've adopted aren't consistent with a DevOps methodology. You can call what you do at your organization "DevOps," but if you don't follow the basic software methodology principles, it's not DevOps. Period.

Here's a set of objective criteria you can use to determine whether what you're doing is truly DevOps. You're really doing DevOps if...

[ Learn how value stream mapping can benefit your organization in this Oct. 8 Webinar. Plus: Learn more with this GigaOm Research Byte on VSM. ]

You have frequent, rapid release cycles

Your work in process (WIP) should be limited to a level that minimizes any opportunity for bottlenecks to form in your delivery pipeline. When a change is ready to move through the pipeline and the pipeline can receive it, you should deploy it. Otherwise, you're holding up the pipeline.

[ Learn how release orchestration can govern compliance, control, and integration for successful DevOps transformations in this Webinar. ]

Deployment to production is fully automated, and you can automatically roll back

Manual deployment is error-prone and slow, two qualities that are decidedly un-DevOps. Because nobody's perfect, and sometimes things go wrong, automated deployment is the way to go. You want to be able to quickly and reliably back the change out if there are problems, so you'll need to have a tested rollback plan for each change, whether that means reversing a change, or toggling a new feature off.

You do continuous integration with automated testing at every check-in

As with deployment, if you're building manually and testing manually, you're introducing avoidable delays into the pipeline. Developers should be checking into the version control system regularly, and that event should automatically kick off a build and a battery of automated tests. If the build or any tests fail, the team should be alerted immediately.

This applies to all code, not just application code. For example, infrastructure scripts required for deployment should be treated as code, checked in, and tested automatically.

You have far more resources devoted to automated testing than manual testing

Is there a place for manual testing in DevOps? Ideally, everything should be automated, because manual processes are slow and expensive. That said, there are some things that can't really be automated, such as usability testing. So yes, there's a place for some manual testing. But anything that can be automated must be automated, or you're not doing DevOps.

Your developers, testers, and operations engineers work together

Communication and collaboration is the key to doing DevOps right. If your developers, testers, and operations engineers aren't talking to each other, you're not there. One indication of successful communication is if developers and testers are using production-like systems, with production-like data, for development and testing.

Your developers, testers, and operations engineers have common, business-oriented goals that cover the whole value chain

It's not enough just to talk. Conversations need to be focused on how everyone can contribute to accelerating the throughput of work in the delivery pipeline in order to achieve business goals. You can only do this by collaborating with the business, understanding the business' goals, and providing feedback about the feasibility of the business requirements.

You're paying back your technical debt

If you've had to cut corners to get something done, you're creating technical debt. And just like financial debt, if you don't pay it back, it will compound and eventually bite you. Whether it's bad code or bad practices, you need to fix this at the earliest opportunity.

Management gives the team the authority to make the changes it needs to make—and the team makes those changes

DevOps team members are in the best position to know their WIP limit. They need autonomy and the authority to make the changes they believe are necessary, without management imposing decisions that don't take into account the situation on the ground. Management's role is to guide the team and ask the difficult questions that will promote thought and discussion. If they don't have the expertise, they should bring an experienced coach into the organization to work with the team.

You have feedback mechanisms in place to ensure continuous assessment—and act on that feedback to ensure continuous improvement

Continuous assessment refers to all the feedback loops that are key to DevOps. You don't want to find out from your customer that your website isn't working. You need to have a system of checks, balances, and monitors in place so you can pinpoint when and where something has gone wrong, resolve the problem as soon as possible, and add checks to make sure it doesn't happen again. Sometimes the problem seems obvious. For example, when you deploy a change and the system crashes second later. But what if it was a disk drive that failed? Or a network cable fell out of one of the servers?

Using system health dashboards for continuous monitoring of the application and the platform on which it runs will keep you on top of your systems. You also need to receive continuous feedback from the team, assess the processes by which the application and its environment are delivered, and make sure that you're meeting the business goals. When you identify an improvement that you can make, go ahead and make it. If you can't find anything that needs to be improved, look harder.

Doing DevOps is all about optimizing and improving the end-to-end flow of new features to meet business demand. It's business focused, not IT focused, and it's always improving. If you're doing all the things I listed above, then you should be enjoying the rewards of DevOps. Are there other things that are essential to DevOps that you'd add to this list?

[ Learn what separates successful DevOps initiatives from unsuccessful ones in this new EMA research webinar. ]