Applying Change Approval Policies to DevOps

[Jason Occhialin]

Previously, we discussed what Change Approval Policies are, how to use them, and how powerful they are right out of the box. We discussed how the change_request policy input we supply with the Normal and Emergency change approval policies, by default, provides seamless access to variables in the change request table or any table it references. That’s huge on its own, but what if we want to reference fields and values in a table change request doesn’t reference? What if our DevOps teams store their test results in Test Management and we want to use that information to dictate an automated approval or rejection? Test execution suite for your service which is being changed under CHG100001 is 100% complete and successful? Automatically approve for deployment. If the test suite has too many failures? Automatically reject it and approval can be requested again when the work is ready to deploy.

Change Approval Policies allows us to easily accomplish this.

Note: I have activated the Test Management 2.0 plugin with demo data for this example

Based on what I said above, you can easily understand how the change request Policy Input can be used to provide access to another table, right? If a table isn’t currently referenced by change request, create a reference field from the table and it’s easily accessed.

The other and potentially more powerful way is by creating a new Policy Input. If we take a look at the base system Normal Change Policy, there are two existing inputs: change_request and manager_approved. These serve as great examples.

Let’s create a new policy input and define it as a Reference to the Test Execution Suite (sn_test_management_test_execution_suite) table for our DevOps example. The idea is, when the test suite associated with the service which is being modified exceeds certain thresholds we have previously agreed to and defined via policy, automatically approve that Normal change as the product owner for the team.

Our new Policy Input will look like this:

 

Now that we have a Policy Input that references our test execution suite table, that input can be evaluated in a Decision within our policy. The next step is to create the Decision that references information in that table.

Our new Decision may look something like the following. Make note, that I have distinguished this Decision from our standard Assess Technical Approvals Decision by specifying a new category value of DevOps and am then planning to use the results of an automated test suite – was it 100% completed and did the percentage of tests passed exceed our agreed to threshold of 95%, to determine an approval action. 

 

I also went into the Assess Technical Approvals Decision and added a condition to exclude the DevOps category. Why did I do this? When the conditions in my new Decision are true this is the only Decision and Approval action I want to trigger.

 

Now let’s go create that answer or approval action. If we achieve this agreed to threshold, I want to automatically approve this change. To do so I’m going to take advantage of our base system Normal workflow which allows low risk Normal changes to be approved at the group level and if the manager of that group approves in the Assess state, we bypass the Authorize state entirely. With that in mind, I’ve defined all my DevOps teams assignment_group.manager value to be the product owner of the DevOps team. 

This aligns with a core belief we have of empowering teams. Change Management doesn’t have time to be mired in every low risk change that needs to be performed. We need to be focused on the activity which presents the greatest risk and impact to our services. By maximizing use of the standard change type and empowering teams to do the right thing on lower risk activity we’re able to better focus on the activity which actually needs more governance.

Recalling how approval definitions work, I’ve chose the Approval Action Approve which automatically approves when triggered, chose the Approver source to be Change Request because I want the manager derived dynamically, and chose the user field to be the Assignment group manager. It was so tough, it took all of thirty seconds.

How do I make sure my policy evaluates the right test execution suite? Let’s go configure our workflow to ensure the test execution suite policy input is defined when the Change Approval Policy activity is executed. As we have changed the Normal Change Policy, we will continue by editing the Change Request – Normal workflow. This workflow has two Change Approval Policy activities, the first is named Technical approvals which is the Assess state approval gate and this is the activity we will modify. Once I check out the workflow and open the Technical approvals activity, take note of the Policy Input field. This is a standard script field where the result of the script is an answer object. The answer object is where new policy inputs can be defined and where we will add the “u_test_execution_suite” input we defined earlier.

 

In this example, how will we derive the appropriate test execution suite? Our input will look for the change request number in the short description field of the test suite record and will look as displayed below. If a test suite can’t be found, the policy input won’t be defined and the decision we defined which referenced it won’t be considered when evaluating the policy. Obviously, this is an example. You can key off any relationship between the two records.

Now that we’re done, I re-publish my workflow.

Testing our new Policy Input

Ok, so we have defined a new Policy input referencing Test Management. We created a Decision to reference it and defined an answer or approval action to trigger when that Decision evaluates to true. Let’s go see this thing in action.

I’ve defined this super detailed change request. Note my Category is the DevOps category my Decision referenced, and my Assignment group manager is Fred Luddy. You can also see in the Process Flow Formatter my state is New. I’ve yet to request approval.

I also have a Test execution suite whose Name (short_description) is the same as my change request number. Note that it’s 100% complete and 100% of my tests passed.

Alright already, get to it. I go back to my change request and request approval and BAM! Bam, what? Well, first off my change has been automatically authorized for deployment and didn’t require a single manual approval.

I can see in audit history, there was only a single state transition.

How do I know who approved it and how? We generated a standard platform approval record which was approved by our product owner, in our case the assignment group manager.

How do I know it was approved automatically through our approval policy? We track every application of that policy.

There you have it. Change approval automation for your DevOps teams, powered by Change Approval Policies. Go put them to work for your teams.