Maturing DevOps with the inclusion of Approvals
I found a lot of teams get stuck focusing on the automation side of DevOps, how to do builds and deploys, sometimes they include testing automation. Whilst this is a great place to start, and automation is a key enabler, it is not the whole of DevOps.
Automation enabled DevOps, has been a fundamental pillar of the movement since inception, but a singular focus on automation won’t deliver a successful DevOps practice. — 2021 State of DevOps Report.
I wanted to share a point of view on how to mature your DevOps so its not just focussed on automation. This is a view that I have run into many times over the years working with organizations in implementing DevOps or evaluating their maturity.
To make DevOps successful I truly believe that you need to work with the organization, the teams, the people, and understand the current processes that are interwoven into their way of doing things and identifying areas of gain, pain, and friction, and how to work with them.
One such area that really helps, is incorporating approvals. Think of them as a form of feedback and streamlining the ability for all users of DevOps (not just Developers) to provide this feedback.
I find that approvals are a major part of all business processes. It might be a change board that meets every 2 weeks, or an ITSM form that is needed before promoting between environments, or it might be as simple as the sign-off from the Quality Assurance team.
The vision
What we are after is the ability for all users to provide their feedback (approval / disapproval) in an easy to consume and easy to incorporate method.
We want to be able to collect this feedback, that may be tracked elsewhere, from all stakeholders irrespective of silo or stream or platform team that they are from. If they are part of the business process then they should have a means for providing feedback and the better we can get this feedback incorporated, the more we can reduce friction and speed up the cycles, and in turn, mature our DevOps.
In part, an approval, is really just a part of an integrated feedback loop. Another way to view this would be to ask the questions you would find in a meeting:
- Are you happy with the quality of said release / feature?
- Are you happy for us to proceed with rolling this release / feature out?
The Requirements
Lets peel back the layers and see what we need to achieve to make this a more streamlined incorporated process. These are real requirements that were collected from teams through workshops and enhancement requests inside a very large organization.
- Ability to indicated / enable if approvers are required
- Approval only being required prior to the deployment phase
- Ability for one or more approvers
- Ability for a minimum number of approvals to be required
And for advanced bonus points
- Ability for approvers to be a part of a group, and
- Not all members in the group need to provide approval
💡 Think of a release management group and only needing one release manager to give their go ahead.
The Concept
The following concept was designed by an amazing designer and was implemented on a CI/CD system that provides a self service experience on top of Tekton.
In the above design you can see that we have managed to provide a configuration mechanism available to the development organization to
- Enable approvals
- Add approvers
- Mark certain approvers as required
- Require a certain number of approvals
But what about the approvals themselves? We need to make the consumption and actioning of the approvals smooth and minimise the interaction friction.
This means we needed to separate it out from concepts these users may not appreciate or would add confusion. Whilst this screen doesnt have all of the information, for example quality data can be linked to from the version to load up a quality dashboard, the users see the actions they must take.
💡 Investigate policy as code to ensure quality metrics are met before you get to human approvals, and as trust in the system is gained, work together to create a policy that removes the need for a human approval.
💡 You could even go further and ensure that these approvals made their way back to an ITSM system for tracking if needs be.
Summary
This is just an example of how you can work with the members of an organization, the users, to bring more of the business process into DevOps and grow your maturity.
If you are really set on driving everything through automation, then think of this as automating the business.
Show your support
Thanks for reading! If you made it this far, show your support if this helped you:
- 💬 Follow me on Twitter
- 🙏 Join my opensource project and help contribute
