For a practitioner of Release Engineering, Continuous Delivery is not merely just utilizing tools and doing some automated activities. It has to request everyone involved in the process of delivery to coordinate together to achieve the delivery goal. In this article I will introduce two Continuous-Delivery-Maturity-Models and explore how we can practice them in our continuous delivery activities.
The first Continuous-Delivery-Maturity-Model I want to introduce here is from http://www.infoq.com/articles/Continuous-Delivery-Maturity-Model
The model defines five maturity levels: base, beginner, intermediate, advanced and expert in five categories Information & Reporting, Test & Verification, Build & Deploy, Design & Architecture, and Culture & Organization. I think the advantage of this model is, it considers not only from the view of DevOps, it also consider Culure & Organization. Sometimes, the organization and it’s culture are probably the most important aspects to consider when aiming to create a sustainable Continuous Delivery environment. I ever worked for a company with a specified Build & Release Team however due to the company culture the team get dismissed after some years. So understanding how maturity of your company is can give you an understanding how far the Continuous Delivery and even the Release Engineering team can go.
However from the view of Release Engineers, the maturity of Culture & Organization is a bit out of control. A Release Engineer sometimes can not do much to change the Culture & Organization. And, in this model, it also introduces the maturity of Design & Architecture, we all know that as Release Engineer we need to involve into the architecture Design and also understand that the design and architecture of products will have an essential impact on our ability to adopt continuous delivery. But now, what I just want to share in this post is, how to manage your continuous delivery given that you have to go with your current architecture and organization culture. Hereby I will introduce another Continuous-Delivery-Maturity-Model below. It is a model listed in Book <Continuous Delivery – Reliable Software Releases through Build, Test, and Deployment Automation> and Continuous Delivery: A Maturity Assessment Model.
The model has 5 levels in categories ‘Build Management & CI’, ‘Environment & Deploy’, ‘Release Management (Compilance)’, ‘Testing’, ‘Data Management’, and ‘Configuration Management’. Let me summary them as below:
Level-5: Optimizing,
Build Management & CI: Every team has a fixed time to update each other, discuss integration problems, and can fix problems in an automated, faster feedback, and visual way.
Environment & Deploy: It can manage all of the environments effectively, all of the environment preparation can be automated and if possible, can use virtualization technology.
Release Management (Compilance): DevOps and delivery teams have a fixed time to co-work together to manage delivery risk and shorten the SDLC.
Testing: The deployment on Production works in most of the time and no rollback. All of the bugs can be found and fixed in a short time.
Data Management: The data for database performance testing and deployment can be reused and can provide feedback between two release cycles.
Configuration Management: Can review regularly whether configuration management can support an effective cooperation among teams, a fast development and an audit-able changes management.
Level-4: Quantitatively,
Build Management & CI: The build can not be in a Fail status for a long time and it should collect build metrics.
Environment & Deploy: The deployment management is being tracked carefully and the process of release and rollback can be tested.
Release Management (Compilance): The health of environments and application can be monitored in an early bird and cyclic way.
Testing: The quality can be tracked and metrics-ed and all of the non-functional requirements can be defined and metric-ed.
Data Management: It should monitor and optimize the database and the database upgrade and rollback testing can be taken care for every deployment.
Configuration Management: Developers should commit once into the mainline every day and should create a branch only when it is time to have a release.
Level-3: Consistent,
Build Management & CI: Check-in build and check-in testing. Dependencies can be well managed. Tools and scripts can be reused.
Environment & Deploy: Software Delivery can be automated and it should use an unified to deploy software to all of the environments.
Release Management (Compilance): Define and conduct change management. All of the policies and compliance can be satisfied.
Testing: Automated unit testing and acceptance testing. Testing is part of development.
Data Management: Changes in database can be automated and be part of the deployment pipeline.
Configuration Management: Libraries and dependencies can be well managed.
Level-2: Reproducible,
Build Management & CI: Can build and test software automatically and regularly. All of the builds should based on the latest code from code repository.
Environment & Deploy: All of the environment configuration should be sourced control and separated with source code. It will not cost too much time and effort to create a new environment.
Release Management (Compilance): It is a bit painful to release software but the release should be in a good quality. Part of the configuration from requirement inception to delivery can be tracked.
Testing: Automated testing is part of the development of user stories.
Data Management: Changes in database can be automated and can be sourced control.
Configuration Management: Source codes, configuration, build & deploy scripts, and data migration can be sourced control.
Level-1: Retardative,
Build Management & CI: Software build is in a manual way and can not manage artifact and reports well.
Environment & Deploy: Software deployment is in a manual way and the software packaging is environments dependent. The preparation of environment is manual.
Release Management (Compilance): Can not release in a good quality frequently.
Testing: Can do manual testing only after developments finish.
Data Management: Database migration is in a manual way and doesn’t do version control.
Configuration Management: No source control and the commit is not frequent.
This model is a very good and with a high practicability. As a release engineer, we have to involve into all of the categories ‘Build Management & CI’, ‘Environment & Deploy’, ‘Release Management (Compilance)’, ‘Testing’, ‘Data Management’, and ‘Configuration Management’ in our daily jobs. I think this model can help enhance our Continuous Delivery definitely.
I believe that we can use this model as our guide and it will help us to do continuous improvement.
Bad Quality Organization 