The Doppler Quarterly Winter 2016 - Page 13

MATURITY LEVEL Level 1 Ad-Hoc Level 2 Repeatable Level 4 Measured Level 5 Optimized PEOPLE PROCESS TECHNOLOGY • Silo based • Blame, finger pointing • Dependent on experts • Lack of accountablility • Manual processes • Tribal knowledge is the norm • Unpredictable, reactive • Manual builds and deployments • Manual testing • Environment inconsistencies • Managed communications • Limited knowledge sharing • Processes establishes within silos • No standards • Can repeat what is known but can’t react to unkowns • Automated builds • Automated tests written as part of a story development • Painful but reapeatable releases • Collaboration exists • Shared decision making • Shared accountability • Processes automated across SDLC • Standards across organization • Automated build & test cycles for every commit • Push button deployments • Automated user & acceptance testing • Collaboration backed on shared metrics with a focus on removing bottlenecks • Proactive monitoring • Metrics collected and analyzed against business goals • Visibility & predictability • Build metrics visible and acted on • Orchestrated deployments with auto rollbacks • Non functional requirements defined and measured • A culture of continuous improvement permeates through the organization • Self services automation • Risk & cost optimization • High degree of experimentation • Zero downtime deployments • Immutable infrastructure • Actively enforce resiliency by forcing failures Figure 1: The DevOps maturity model focuses on the degree that an organization is able to obtain value from DevOps processes and technology. Some development organizations attempt to separate development and operations groups, but that route quickly becomes dysfunctional. A better approach is to combine them into a single role: a DevOps man- ager. As your development needs expand, increase the number of DevOps managers you have. This keeps organizations small, nimble, and focused on a specific purpose within the systems they build and operate. Step 4: Define a DevOps Process There are many resources that tell you how to define a DevOps process, which is simply automated agile. However, there are as many types of DevOps pro- cesses as there are types of organizations, so you’ll have to pick the one that best suits your needs. Figure 2 shows a complete DevOps process you can use as a starting point. You may not need some of the steps, or you may have to add more. What should be consistent is your support for continuous develop- ment, integration, testing, deployment and opera- tions. The tools and the steps you use will vary based on your business and technology requirements. DevOps in the Cloud This process typically spans traditional platforms, such as a Linux, Apache, MySQL, and PHP/Python/ Perl (LAMP) stack, to newer public or private clouds. Figure 2 shows a typical demarcation line. However, the process can span all cloud platforms and cloud DevOps tools, or all traditional platform and on-prem- ise DevOps tools. Step 5: Define Your Target Cloud Platform Defining the target platform for application hosting is important for two reasons. First, the target platform has a great deal to do with the DevOps tools you select, especially operational automation tools. Sec- WINTER 2016 | THE DOPPLER | 11