UrbanCode Velocity

Release Management with UrbanCode Velocity and ServiceNow

Release management is a fundamental aspect of making changes to enterprise software environments, whether those changes are toward applications or infrastructure.  It’s important to secure a repeatable process for doing so, especially when releases become more complex across various teams and business units.

UrbanCode Velocity offers an easy to use, templatized release management solution, with a native ServiceNow integration to keep your change and release management processes in tight sync with one another.  In this blog, we will walk through how to set up an enterprise release plan in UrbanCode Velocity, tied to ServiceNow, and deliver software to a production environment.

1. Create an Enterprise Release Template in UrbanCode Velocity

The first step is to create an enterprise release template in UrbanCode Velocity.  This template represents the process that will be executed every time we want to release new software as part of a major release event.  Think of this as the ‘parent’ plan for orchestrating releases across teams, business lines, or any group that wants to go to production as part of this event.

Notice the option ‘AutoStart plans created from this template when a release is created’.  When the ‘Yes’ box is checked, every time a Release is created in UrbanCode Velocity, a linked ServiceNow change ticket will also be created.  In this case, we’re going to set it to ‘No’, so the change ticket will be created after we start the release execution in section 3.

Once we’ve created our template, we define the tasks for the release to follow each time a release is created from the template.  Here is where we set up our integration with ServiceNow, establish governance through approvals and notification tasks, as well as set other automated or manual tasks.

For integrating with ServiceNow, we define a series of ServiceNow type tasks that create and update change tickets as a release plan is executed.  The first task will be to create the change.  The following screenshots show an example configuration showing the Create Change Ticket task that connects to ServiceNow.  There is a lot of flexibility in how this can be configured, depending on how and when you would like your changes to be updated in ServiceNow throughout the release process in Velocity.

 

Notice the ‘ticketId’ field we are setting.  This creates a property that we will reference in later steps to make sure we are updating the newly created ticket as the release progresses.

Another type of ServiceNow task that we can create is to wait for change ticket approvals.  To do this, the action ‘Wait for change request’ must be selected, with the relevant field and value that we are waiting on to be set.  When the release plan reaches this step, Velocity will poll ServiceNow based on the set interval, until those field and values match what is set.  In this case, the task will be ‘In Progress’ until the ticket is approved.

Notice that the System ID field is referring to the ‘ticketId’ property that we set in the ticket creation step.  This property can have any name, as long as it is consistent across tasks for Velocity to use.  Also note that this property is not inherited by child plans, so other templates can use the same property name without conflict.

The last type of ServiceNow task we will use is the ‘Update change request’ action. Similar to the ‘wait’ task, this will use the System ID to reference the ticket created in the beginning.  This time, instead of waiting for changes to occur in ServiceNow, we can use Velocity to make changes to the ticket in ServiceNow.  The ‘Additional properties’ field lets you update a field with a new value, using the ‘field=value’ syntax.  In most cases, we will be updating the ticket to a new ‘state’, such as ‘Implement’, or ‘Scheduled’.  It’s important that the updated value is allowed in ServiceNow based on the current state of the ticket, or the task will fail.

The default ‘state’ values in ServiceNow are shown here.   The ServiceNow API uses these numbers to assign the value.

After we have configured our ServiceNow tasks, as well as other enterprise release administrative tasks, we can add the plans of other templates as deployment tasks to configure governance over the larger release.  As mentioned, this ‘enterprise’ plan is the parent to the plans which will deploy the software.  For every pipeline stage created in Velocity, there will be a corresponding template.  To add these templates to the Enterprise plan, we use the task ‘Run another plan’.

For this use case, I am assuming that I have already set up the JKE-Pipeline PROD stage template.  This template looks similar to my enterprise plan, however, it contains the tasks for actually deploying the software through either Jenkins, UrbanCode Deploy, or Ansible.  By referencing this plan in my ‘Run another plan’ task, I am able to orchestrate one or many deployment plans via my enterprise release plan.

Now, I have completed the templatization of my enterprise release plan.  All of this work should be a one-time effort, aside from tweaks here and there to change or improve the overall process.  Every time my organization wants to run an enterprise wide release, we will start an execution from this template.

2. Creating a Release to be Executed

Now that my templates are created and synced up with ServiceNow, I am ready to run my first release.  The first step is to create the release.  The following screenshot shows an example of an enterprise release being created from a template.

Notice the use of tags, to make it easier to search and find later.

Once my release is created, my teams and business units will have the ability to join this release with their deployment templates.  The example we use here is again for the ‘JKE-Pipeline’.  To join an enterprise release, simply click on the arrow next to your PROD stage, and click ‘Join Release’, as shown.

From here, we will be given the options of what releases we want to join, and with what application versions we want to deploy with the release.  By default, the versions in the nearest stage are selected, in this case, these are my versions already delivered to my ‘QA’ stage.

Once I click ‘Schedule’, my Enterprise Release plan view should now reflect the newly joined JKE-Pipeline team plan.

3. Executing an Enterprise Release

In section 1, we showed how to create an enterprise release template.  Section 2 showed how to create a scheduled enterprise release and how various teams are able to join.  This section will describe an example execution of that release.

To begin a release, simply click the play button on the first task of the Enterprise Release.  This will create the ServiceNow ticket and start the release clock.  Remember at the beginning of this tutorial when we had the option to ‘Autostart plans created from this template’?  If we had selected ‘Yes’ here, the plan would already have started when the release was created, and would be waiting on the next subsequent manual task.  In this example, we are starting it ourselves.

Now that our release has started, we will pause on the Wait for Approval in ServiceNow task.  To approve the ticket in ServiceNow, we must log in to the ServiceNow server, request approval of the change, and let the designated approvers approve the change.  In a real execution, this process will involve various stakeholders across both the Velocity tool and ServiceNow tool.  Since we have set them up to be in sync, all of the updates will occur automatically once the approval has been given in ServiceNow, and the Release plan will continue on.

When the enterprise release plan reaches our self-defined ‘deployment’ tasks, we will see that the PROD template that joined our enterprise release will begin execution.  The following screenshot shows an example of what this PROD template looks like.

Notice that this template also contains its own integration with ServiceNow.  This is because in this example, we are creating a ticket for the enterprise release itself, and for every team or group of apps we are releasing along with it.  That way, we can govern the approvals and changes not just at the enterprise level, but at the more granular team and application level as well.

When the deployments through Jenkins and UrbanCode Deploy are complete and the ServiceNow tickets updated, the plan will return a success for the Enterprise plan to move on.  If we check the scheduled release page, we can see the change tickets that we created are linked and visible.  In this case, we have one for the enterprise plan, and one for the pipeline PROD deployment that joined it.  If many teams had joined this enterprise release, we would see many tickets here.

Likewise, in ServiceNow, we can see these change tickets, which were created and managed by UrbanCode Velocity.

Now that my Enterprise Release plan has succeeded, I can see this on my release summary page.

I can also go check the pipeline that joined this enterprise release.  In the pipeline view, I can see that the latest versions that I selected from my QA environment are now deployed and running in Production.

Tags:

UrbanCode Velocity