I’m not your typical DevOps evangelist. I don’t believe continuous deployment is right for every business as it requires significant technical maturity to enable this level of automation. It’s far more important for organizations to align their release management practices to business need and then prioritize the work on CI/CD that reduces the most manual, risky efforts tied to integrating and delivering applications.

I also believe that DevOps requires a new collaboration between Dev and IT that drives collaboration on both delivery and reliability objectives, however,  I don’t believe this can only be achieved by reorganizing and having Dev and Ops in one squad or team. That’s just one potential way to accomplish this objective that might work in startups and smaller organizations, but may not be practical in larger ones.

Lastly, while many organizations focus on CI/CD as their first step into DevOps, it may not be the best option. First, I firmly believe that some form of continuous testing is needed before overly investing in CI/CD automation. No use deploying code full of defects. Second, for applications that are already in production, I would consider investing in robust application monitoring or enabling environments with Infrastructure as Code and containers before implementing CI/CD.

Like I said, I’m not your typical DevOps evangelist.

A Formula to Help Prioritize DevOps Implementations

The first thing I look for in prioritizing DevOps practices is to do an application review and score application against a normalized set of dimensions:

• X = Pain points in managing the application in production
• Y = Pain points in delivering application changes required by the business
• Z = Relative business importance of the application

Your DevOps Priority is then f(X,Y,Z) with some considerations to handle some boundary conditions. New applications will have X=0, but may be smart to invest in if the business importance of the application is very high. Similarly, for mission critical legacy applications (high X, low Y, high Z) it may be better to develop risk mitigation strategies rather than investing in DevOps practices.

I’m also leaving out a fourth metric on complexity (C). If you’re early in your DevOps learning curve, then you might bypass complex applications and start with the easier ones.

Once you score f(X,Y,Z), handle some boundary conditions, and filter applications that are too complex for your team’s skills, then you can more easily review what practices to apply specific to the business and application needs. For applications with high X values you might start with CT (continuous testing) and CI/CD. Other applications with high Y values may improve with better monitoring or establishing IaC and containers.

You are probably saying that this is common sense, and it is, but it’s not how many organizations dive into DevOps. If the momentum is driven by Dev, then you’re more likely to see investment in CI/CD and maybe containers. If it’s driven by Ops, they are more likely to start with IaC. And they may be starting with the applications with the most pain points from their perspectives – not necessarily from business criticality.

Like I said, I not your typical DevOps evangelist. Take a moment to measure f(X,Y,Z) and you might find some surprises.