Organisations utilises industry standard Information Technology Infrastructure Library (ITIL) framework which is embedded within the IT discipline. ITIL provides list of practices for Information Technology Service Management (ITSM) ensuring IT services aligned with business needs. One of the key component of ITIL is Change Advisory Board (CAB) taking care of change control. CAB is defined with an approval process involving respective representations from various IT functions. CAB’s main aim to ensure the process of change control.
Change Control is one of the key process ensuring all changes that goes into a production system implemented in a controlled manner. This ensures all relevant stakeholders are aligned, risk agreed, less impact to system downtime etc. It also ensures any unnecessary changes not going through and does not introduce any unnecessary faults in the system. While this provides benefits for the organisations but also introduces delays. At the very least the delay would be a week and then spanning out to months or in other cases converting that into an emergency change forcing CAB to be quick. This is not going to be sustainable in the long run especially for a DevOps team who would continuously want to release new features.
ACS embraces agile and lean practices at its core and encourages teams to release small changes more often. It is always a big risk to release bigger changes into production which would need a clear understanding of what the change is before the release. ACS ensures the adoption of automated change control. Most of the controls that is being used in the normal change control process can be automated. Here are a list of checks that are normally done
- Build : Coding Standards, Static Code Analysis
- Test : Coded Tests / Code Average, Acceptance Tests
- Deploy to Staging : Setup environment and infrastructure, deploy, smoke tests
- Deploy to Production : Setup environment and infrastructure, deploy, smoke tests
Release into product will be done only if all stages are successful.
All of these can be automated and embedded as part of the CI/CD pipeline ensuring all the checks are satisfied before being released. There are various other companies who have adopted some best practices. Atlasssian is a very good example who has adopted some of the best practices for change management in DevOps. Here are their core principles
1. Embrace Agile and DevOps principles to reduce human effort and errors
2. Autonomy over authority for rapid decision making
3. Plan for releasing change from the very beginning, without adding extra processes
4. Minimize the negative impact of change by preparing for failures and incidents
5. Address both internal process pain points and customer pain points to change
Conclusion
DevOps teams have to move away being delayed due to change control to adopting automated change control. This might take a while for the teams to implement and setup automated change control as a practice but it is worth the effort. Also this will increase the efficiency of the DevOps by way of releasing small changes more often and building the trust along the way. Once change advisory board starts trusting the team then it can provide autonomy to the teams to self manage.
