Hot or Cold? Temperature Check!
I’ve been thinking of a story that a friend told me once. A story about her son. He kept on questioning what clothes he should put on. Always when they were getting ready to leave the house, the same questions. It drove her crazy. Do I need a coat? Why do I need a coat? Can I wear my fleece jacket? Can I wear a short sleeved shirt? Do I have to wear a coat? Can I leave my coat at home?
His mom had a clever solution. She placed a thermometer next to the entrance. She marked up to 55 degrees as the range for the coat, between 55-65 as the range for the fleece, and above 65 as the short sleeved shirt range. Now he could decide on his own. It saved her five minutes each time. 58? Fleece! 40? Coat. When he asked her how to dress, she just pointed to the door with the thermometer.
It would be great if we had the same process for our change tickets. The faster we go in DevOps, the more changes we get for approval. How can we keep up the pace if we don’t improve our processes? We have to automate the approvals for changes, but with a thermometer that measures risk instead of temperature.
Is the change (risky?) hot? We’d better do a manual approval. An everyday change? Don’t bother me for that, look at the thermometer.
Check. Low Risk. Approved. This saves time!
I see that the number of low risk changes, in particular, is increasing. That’s because the releases are getting smaller, the frequency higher. At the same time, we know more about the changes in a sprint then we ever have. The pipeline and the automation makes the quality transparent. Our real time dashboard shows the audit trail and let us double click into the stored artifacts like test results, scan results and approvals.
To automate the approvals for low risk changes, a thermometer at the door is required. A thermometer that takes multiple factors into account. The first factor is obviously the risk classification of the application. But besides that, three more topics should be in focus:
The maturity of the pipeline
The type of change
The track record of the team
The maturity (1) in DevOps describes the pipeline and capabilities in place: automated unit tests, automated quality scans, the use of feature tokens etc. To allow teams to use the automated change approval process, a minimum maturity is required. A minimum pipeline. Or how we call it: the minimum lovable pipeline.
Another factor in validating the risk of a change is its type (2). Do I change the .css file? Do I change the database schema? Just a few new lines of Java code? A major new feature with external interfaces?
To notice the track record (3) of the team in our approval process is something we know from the manual approval. It may perhaps not be explicit. But we all know that statement in one or another form: “That’s the team from Karen, that’s fine. They never make trouble in production!”
With DevOps, deploying changes in production is daily business. But to increase the speed, an investment in automated change management is required. Manual approvals will simply not do the job - it’s not efficient and will drive us crazy. We need a thermometer at the door to our production systems.
Scaling DevOps requires automating the approvals for low risk changes in production