Better together: Continuous Delivery for PE and ServiceNow flows
Continuous Delivery and ServiceNow flows: better together
Continuous Delivery for Puppet Enterprise (PE) is a tool for streamlining and simplifying the CI/CD process of your Puppet code. Continuous Delivery for PE offers a prescriptive workflow to test and deploy Puppet code across environments. ServiceNow includes a powerful Flow Designer. Why not combine Continuous Delivery for PE pipelines with the ServiceNow Flow Designer to improve and automate your change management process even further?
Change management mostly distinguishes between simple standard changes and more difficult changes. Standard changes can often be allowed as a category just once by the Change Advisory Board (CAB), after which each instance of that standard change can be implemented without further CAB involvement. Regular changes always need a CAB approval before implementation can start. Saying this, why not leverage Continuous Delivery for PE to get information about the complexity of a Puppet code change and use ServiceNow Flow Designer to automate the approval of standard changes?
Curious how this can work? Let’s put things together and get it working.
Continuous Delivery for Puppet Enterprise can work with the API of ServiceNow and create a change request in ServiceNow automatically. The pipeline step, a Continuous Delivery for PE custom deployment policy, is available at the Puppet Forge for free download. ServiceNow can work with the API of Continuous Delivery for PE to promote the pipeline in Continuous Delivery and even approve code deployments that require approval.
The following description on how to set up Continuous Delivery for PE and ServiceNow is based on a change process. For our change request approval process we decide that change requests containing only nodes with 10 or fewer Puppet resource changes (add, modify, delete Puppet resources) are considered simple standard changes and are allowed to to be implemented in the Production environment without further CAB approval. All other change requests have to follow a different process and get approval in a CAB meeting.
Set up Continuous Delivery for Puppet Enterprise
Continuous Delivery for PE comes with a powerful Impact Analysis capability. This Impact Analysis shows you which Puppet resources on what nodes will change if you proceed with deploying the code changes into (in our case) the Production environment. The Impact Analysis plugs into your Puppet Enterprise (PE) instance and compares the current state of each node affected by the changes with the state resulting from the changes. The following images illustrate an example Impact Analysis for a Production environment. The first one shows the summary view.
The second image shows the node overview with all affected nodes and the number of Puppet resources changed. A click on View details will show all changed Puppet resources for the selected node.
Let’s start setting up the custom deployment policy needed to communicate with the ServiceNow API. This article will not cover how to construct pipelines in Continuous Delivery for PE. You can find the documentation on that topic here.
The following picture is part of a Continuous Delivery for PE pipeline and shows the Impact Analysis step followed by the ServiceNow Change Request step.
If the Impact Analysis finishes without any errors, the next step to create the change request in ServiceNow is auto promoted. Auto promotion means the pipeline proceeds without user interaction. And that’s the reason auto promotion is disabled after the ServiceNow Change Request step. Remember, we only want the pipeline to proceed to the Production deployment step after the change request has been approved in ServiceNow and promoted to the implementation stage.
For our change management process the important information is max_changes_per_node. For our example setup we decided that if there’s one or more nodes in the Impact Analysis having more than ten Puppet resources changed, the change has to pass the CAB and can not get an auto approval. The max_changes_per_node parameter configures this number of resource changes. This parameter controls if an Impact Analysis is considered safe or unsafe. Safe means that the change can proceed without CAB approval, unsafe means the change has to pass the CAB for approval. The ServiceNow Change Request module adds a line to the change impact analysis content, classifying the change as safe or unsafe.
The ServiceNow custom deployment policy in Continuous Delivery for PE talks to the ServiceNow API to open a change request, populating several fields in the change request. One of these fields is the Risk and Impact analysis field of a change. Continuous Delivery for PE populates in the Impact Analysis results into the Risk and Impact analysis field and adds one more line at the end. This line contains a short text if the Impact Analysis is considered safe or unsafe.
The image above shows what Continuous Delivery for PE puts into the Risk and impact analysis field. Note the last line Impact Analysis: safe. This information is created from the configuration in Continuous Delivery for PE (max_changes_per_node parameter). Having this information in the Risk and impact analysis field we can create a flow in ServiceNow to control the change process using this information.
Set up the flows in ServiceNow
The following setup shows very basic flows in ServiceNow to control auto approval of changes. Depending on your environment and your processes, these flows can be much more complex. But let’s keep it simple for this example. The first flow we create will move the change into the Implement state, so that a business rule (created by the ServiceNow Change Request module) will trigger Continuous Delivery for PE to approve the next step in the pipeline and deploy the code to our production environment. ServiceNow connects to the API of Continuous Delivery for PE and triggers the approval. After the pipeline is triggered, the change will move into the Review state. The second flow we create will close such auto approved changes automatically.
Note: the following descriptions are based on a ServiceNow Rome instance.
Create the Implement flow
The Implement flow will move the change to the implement state if the impact analysis is considered safe and it is a standard change, therefore needing no CAB approval.
First start the Flow Designer in ServiceNow. You can simply type flow into the Filter navigator field and the Flow Designer will show up.
Create a new flow. Enter the details into the properties form and save it.
Now we need a trigger to watch for some conditions on the change_request table in ServiceNow. We add a Create or Update trigger which will look into the Category field if it is set to Puppet Code and into the Risk and impact analysis if it contains Impact Analysis: safe.
The image above shows how the trigger should look like. Save the trigger by clicking on Done.
Now we can add actions to our flow. In the end we will have added four actions and our change request will have the Implementation state. Click on Action to add the first action. For all actions we need to work on the change_request table. The next picture shows what this action should look like.
Please keep in mind that you have to first select the Table and afterwards you can select the Record. To get the right records, use the data pill picker right to the Record field. This first action moves the change to Approved and sets the state to Authorize.
Let’s add the next action to move our change to the next stage. Add another action to set the state to Scheduled. The next image shows what this action should look like.
Configure Approval to be Approved and State to be Scheduled. Save the action by clicking Done. That’s action number two. Let’s add the next action to our flow. Now we can move our change to the Implement state. Add another action and configure according to the following image.
The last action is to add a work note to the change request that the approval was done automatically due to a safe impact analysis. The next image shows you how to configure this action.
Add for example the following work note: Auto approved due to safe impact analysis.
Save the action and do not forget to test, save and activate the whole flow.
Create the change close flow
The change close flow will close a change request if the change is a standard change and the change reached the review stage. This flow is not necessary and should only be implemented when closing change requests automatically is okay in your environment.
Start the flow designer and create another flow with only one action. The flow properties you can set are similar to the first flow. The following images show you how to set up the trigger and the action.
The action will set the state of the change request to Closed.
ServiceNow and Continuous Delivery for PE both have powerful APIs on which to build integrated workflows. This article demonstrated a simple interaction between Continuous Delivery for PE and ServiceNow. Continuous Delivery for PE creates a change in ServiceNow, fills in a lot of information into the change request and the change request is moved through the stages and triggers the pipeline in Continuous Delivery for PE to continue with the production deployment. If a change is too complex and is out of scope of a pre-approved standard change policy, the workflow in ServiceNow will not trigger and the change has to pass the CAB to get the approval to move to the Implementation state.