Build your DevOps foundation the way highly evolved organizations do
In our 2018 State of DevOps Report, we surveyed over 3,000 IT and development professionals around the world. Our analysis revealed five stages of DevOps evolution, and the critical practices at each stage that help you get to the next phase of your journey. Additionally, we found that five foundational practices had the greatest impact on the DevOps evolutionary journey.
From previous reports, we already know that DevOps practices predict IT and organizational performance. The 2018 State of DevOps Report takes this one step further by providing a prescriptive and pragmatic approach to adopting and scaling DevOps practices.
Future posts in this series will delve into the nature of each stage. Here we want to provide a brief overview of the foundational practices.
What highly evolved organizations always do
From our statistical analysis, we revealed five foundational practices that have the greatest impact on the entire DevOps evolutionary journey. When we examined each of these practices more closely, we found that highly evolved organizations were much more likely to always be using these practices throughout the evolutionary journey than the less-evolved organizations. What we take from our findings is that the foundational practices listed below are integral to DevOps, and critical for DevOps success.
|“We always or most of the time…”||Low DevOps Evolution||High DevOps Evolution|
|Reuse deployment patterns for building applications or services||9%||93%|
|Use a configuration management tool to manage configurations||13%||93%|
|Make monitoring and alerting configurable by the team operating the service||10%||94%|
|Reuse testing patterns for building applications or services||7%||92%|
|Contribute to tooling provided by other teams||5%||99%|
So, where do I start?
One of our recommendations from the 2018 State of DevOps Report is to start with the practices that are closest to production, then address processes that happen earlier in the software delivery cycle. We recommend this approach because application deployment is typically where Dev and Ops collide. Improving collaboration across this one critical functional boundary will not only alleviate deployment pain, but also create repeatable patterns that other teams can then adopt. To that end, as you’re adopting these five foundational practices, we recommend that you:
- Reusing deployment patterns.
- Using a configuration management tool.
- Allowing a team to configure monitoring and alerting for the service it operates.
...Then focus on
- Reusing testing patterns for building applications or services.
- Empowering teams to contribute improvements to other teams’ tooling.
The five foundational DevOps practices
Monitoring and alerting are configurable by the team operating the service
While allowing a team to configure it’s own monitoring and alerting seems straightforward on the surface, it can be challenging to do in practice as it requires both cross-team collaboration and a high degree of trust. Empowering teams to define their own monitoring and alerting promotes sharing which is one of the four pillars of DevOps in the CAMS model. Monitoring and alerting is key to sharing information about how systems and applications are running, and getting everyone to a common understanding. This common understanding is vital for making improvements, whether within a single team and function or across multiple teams and functions.
Reusing deployment patterns
We place a heavy emphasis on improving deployments because application deployment is where Dev and Ops most often meet — and most painfully collide. In our 2015 State of DevOps Report, we found that a high degree of deployment pain correlated with low performance across the board — IT performance, organizational performance and culture are all negatively affected when deployment pain is high.
The main causes of deployment pain are manual handoffs between teams and inconsistencies across environments due to manual processes. The countermeasures to this are:
- Doing smaller deployments more frequently (i.e., decrease batch sizes).
- Automating more of the deployment steps.
- Treating your infrastructure as code, using a standard configuration management tool.
- Implementing version control for all production artifacts.
- Implementing automated testing for code and environments.
- Creating common build mechanisms to build dev, test and production environments.
Once you have a successful blueprint for a deployment, see where it might make sense to emulate the same pattern for other applications—for example, you may identify several n-tier web apps that can be deployed in a similar fashion using similar tools. As we learned from Stages 1 and 2 of the DevOps evolutionary journey, too much variance in the system creates complexity which limits agility. Standardizing as much of the deployment process as possible and sharing patterns across the organization allows teams to spend time on truly differentiating work.
Implement and use a configuration management tool
In the State of DevOps Survey, thirteen percent of the least-evolved category used configuration management “always” or “most of the time.” In comparison, ninety-three percent of the highly evolved teams used configuration management “always” or “most of the time.” A solid foundation in configuration management is a force multiplier. It enables teams to define their infrastructure as code once and deploy endlessly. It eases deployments by ensuring consistency across all environments. It improves both reliability and agility of the infrastructure while also making it auditable.
”Everyone wants to have stability while still being fast; that’s one of the main objectives we have for configuration management.… when you become standardized, you become more stable.” – Tom Sabin, IT manager for cloud & automation, Staples
Reusing testing patterns
Automating testing is one of the harder challenges an organization will face in its DevOps journey. We typically recommend addressing testing after the activities that are closest to production, such as provisioning, monitoring, alerting, etc. are dealt with. However, once you do adopt this practice, it’s important to ensure that testing patterns are shareable. For example, you can encode reusable tests into automated testing tools, and share access to those tools — along with the resulting reports or dashboards — among all stakeholders.
Empowering teams to contribute to other teams' tooling
“DevOps is a human problem.” – Patrick DeBois
As software organizations naturally evolve, teams start by solving their own problems and don’t develop methods for sharing those solutions with other teams. Improvements to tooling are typically manual and ad hoc, and siloed within a single team until some change drives the need to open up to other teams.
Perhaps the most obviously cultural-not-technology challenge, the sharing of tooling nevertheless can be driven from changes such as unifying data or other exposure of operations between teams.
5 stages for DevOps evolution
While every organization has different starting points, they typically face the same challenges as they progress through their DevOps journey. The five stages of DevOps evolution provide a prescriptive and pragmatic approach to adopting and scaling DevOps that also meets you where you are today. If you’re struggling with where to start, we’ve provided a roadmap that will help you achieve success faster. If you’re feeling stuck, we provide concrete ways to get to the next stage.
- Stage 1: Normalize the technology stack
- Stage 2: Standardize and reduce variability
- Stage 3: Expand DevOps practices
- Stage 4: Automate infrastructure delivery
- Stage 5: Provide self-service capabilities
Learn how to implement these DevOps practices
How does your organization implement these five fundamentals of DevOps? To learn more, please download the report. It will help you to identify where in the DevOps evolution you find yourself and chart a path forward.
Alanna Brown is the director of product marketing at Puppet, and has been a co-author of the State of DevOps Report since its inception in 2012.