When I started working as a Configuration Manager back in my days at Motorola little did I know that I’d end up on a journey to find a proper path to make DevOps grow and evolve. But here I am, after a some really long years (13/14 months each… #BadJoke) of traveling on the high seas, researching, implementing and learning, finally reached to a good port, found a cool treasure map and I’m willing to share the treasure I found with you.
Lucky for us, the treasure chest is big, sadly, is too big to fit on a single post. So, since I’ll have to split it into multiple posts, I though I could do it iteratively as well. I’m going to start, in this post, talking about the general idea of the model, and how is structured. Then we’re gonna review the model again, going in deep on each level of it (more about this in a min), and finally we’ll do a third iteration to check the goals and practices of each levels.
Raise the anchor sailor!
The Map
How would you recognize a treasure map? I mean, we’ve all seen treasure maps on the movies, and games before. These pieces of old paper with drawings in them and a big red cross showing were to start digging right? But we’re on the information era, how does a treasure map looks nowadays? In this case, it takes the form of a Maturity Model. Cool, ok, but what’s that (you may ask)? A MM is a tool to evaluate the development and performance growth of a group (or individual). It places an individual’s performance against the established stages of growth and expertise.
Let’s put it in other words. Imagine you have a plant on your desk. A tiny plant you want to make it grow and get big. For that you have a ruler, but an special one. If you place the ruler next to the plant, you’ll be able to measure it. The ruler will tell you if it’s your plant is tiny, small, average, or huge, so you’ll know the size of your plant. But this ruler is special remember? Not only will tell you how big your plant is, but also will tell you how to make it grow to the next size.
A MM works the same way, it allows you to measure your DevOps Team or Area, to understand how matured and evolved it is, and at the same time gives your the steps to follow to make it move to the next stage of evolution, or maturity level.
Process Areas
These steps to go from level I to level II are specific goals that the team will have to accomplish in order to complete the maturity level, and be ready to sail to the next one. If you’re at level I, and wish to reach level III, you’ll have to complete level II first.
The steps are grouped by categories to make them easier to manage and understand. there are 5 categories, that we’re going to call Process Areas , they are:
- Source Code
- Testing
- Environment
- Monitoring
- Templating
The practices grouped in Source Code area are related to code change management, like ensuring its integrity, detecting integration issues, continuous integration implementations, test results reports, code coverage and static analysis, and so on.
The Testing area brings together the practices related to the management of unit tests, functional tests and integration tests. Notice that functional and integration test suites require a running environment, those practices tho are not included in this process area but in Environment , which groups the practices involved in managing the software application execution environments. Specifically in identifying what environments will be necessary (production, test, development, staging, pre-production, etc.), the characteristics of each one, and the processes necessary to create them and ensure that they meet the stated requirements.
Monitoring groups together practices involved in real-time and statistical monitoring of software environments and applications so that erratic behavior can be identified and alerted when they occur (or sooner, if possible).
And finally, the Templating area contains practices to generate patterns and templates of processes and (software) projects to expedite both the start of a new project and the replication of changes and improvements in multiple projects that are based on the same templates. In other words, just as code reuse is encouraged in programming, this area promotes the reuse of solutions found in other processes and projects.
Sailing to the next port
The next stop on our journey are the Maturity Levels. The following post will introduce some of the specific practices and how are they organized into these levels that will eventually help you make your DevOps grow strong and evolve.
But tell me, what do you think about these process areas? Can you match the practices you follow into any of them?
Top comments (0)