Continuous Monitoring and Observability is the final step in the DevOps pipeline, and it is a crucial element in gaining true efficiency and scalability.
In our last two blogs in this series, we talked about the first four critical capabilities you want to consider before embarking on a journey into DevOps.
In part one, we discussed Release Planning and the tools useful to set up your stories. We also looked at how you use Continuous Integration and Continuous Testing to build out your code and test its functionality. In part two, we focused on Continuous Delivery to keep a clear deployment pipeline.
Now, it’s time to look at the final capability of Continuous Monitoring and Observability.
Continuous Monitoring
Continuous Monitoring and Observability (CM) is the final capability for DevOps pipelines. We often overlook this capability and leave it to IT Operations folks to address. The key to “DevOps” is breaking down the barriers between Software Development and IT Operations.
Once we deploy the application and make it available for users in production, Continuous Monitoring alerts the team of any application issues in that environment. For example, you create a story to monitor infrastructure health. Or, you want the ability to analyze logs over weeks and months. This step provides the feedback necessary for the team to understand aspects of the application that require additional work.
A quick note about security: embedding secure coding and infrastructure practices into your DevOps pipeline ensures customers don’t find issues before you. For infrastructure, ensure you maintain CIS patch levels. For code, track and manage security vulnerabilities and SQL injection issues. Include additional stories under the CI Epics for security practices.
Putting It Into Practice
As a rule of thumb, put all your epics and stories on building out DevOps capabilities in your product backlog. 15-20 percent of your sprint need DevOps pipeline effort. Ensure your organization sets governance policies in place to support DevOps practices.
Looking back on all the DevOps capabilities, you can see building out each one requires several sprints worth of effort. As DevOps pipelines evolve, remember, it could take a few years for things to materialize fully. If you implement DevOps for a greenfield scenario, you can setup DevOps capabilities reasonably quickly.
If you work in an organization that already has a QA function and a CISO who runs the Security team, they are the groups you want to connect with first. In my experience, QA and Security love DevOps capabilities and are on-board from day one. The two groups you need on your side are Architecture and Change Management. These two teams are more likely to push back, especially if they can’t see the value in their day-to-day effort. Get Architecture and Change Management on board, so the DevOps pipelines don’t get stuck in red tape.
Finally
As we saw in parts one and two of this series, Release Planning targets all the work that needs to happen for the development and deployment of your software. Continuous Integration and Continuous Delivery capabilities are relatively straightforward, and you can adopt these in a couple of quarters. Continuous Testing takes the longest time to incorporate, but honestly, you won’t gain true efficiency and scalability without test automation. Finally, Continuous Monitoring and Observability allows for feedback to close the loop.
I hope you enjoyed the series. Please feel free to reach out to me if you have any questions!