Configuring ReleaseOps in Zurich

[Jon G Lind]

ReleaseOps is a brand-new product, introduced with Zurich, to provide a process and automation to deploy and validate code from dev to prod in your ServiceNow environments.  It will soon be part of App Engine Management Center, however it is a platform feature and is free to use.  

This initial offering can be fairly involved to configure and requires about 13 steps to complete.  We are working on a more automated and guided solution for future releases, but in the meantime...

DON'T PANIC!

There are a lot of steps, but individually each of them are simple.  Pay close attention as you walk through this article slowly, and go back and verify each one if you think you may have missed something.  And in the event that I missed something in this guide please leave a comment.

NOTE: There are changes to be made in your PROD, TEST and DEV environments, though most will be done in PROD.  Pay attention as I instruct you which environment each step is for with an all-caps DEV, TEST or PROD.

 

Step 0: Request and Install ReleaseOps (DEV, TEST, PROD)

NOTE: ReleaseOps is currently in limited release.  You may request access from the store at https://sn.works/releaseops/store and await approval before continuing.

1. Install the application on all participating instances (remember, this is Zurich only) by logging into each and going to Admin (in the header) and selecting Application Manager. 

2. Search for the store application ReleaseOps (sn_releaseops) and select the one that looks like this:

Step 1: Multi-Instance Management (PROD)

First we will configure the Multi-Instance Management Framework (commonly referred to as MIF). This is used to coordinate the process by enabling communicating securely between environments. The Multi-Instance Management trust relationship, is a hub-and-spoke model, with a handshake that authorizes the sub-prod instances to be managed by the controller (PROD) instance. 

NOTE: It is not necessary that the controller be Prod, but this is a typical configuration.

1. On PROD open Multi-Instance Management > Managed Instances. NOTE: Don't forget the hyphen in "Multi-Instance".
2. Use the Add Managed Instances button at the top of the list.
3. A dialog will offer you the chance to select and add all instances at once by holding down shift.
   
4. Select "Send Requests" button.

Step 2: On EACH Sub-Prod Environment (DEV, TEST)

Next, we will login to each sub-prod instance and approve that request, thus completing the handshake.

1. Wait about 1 minute for the changes to propagate.
2. Approve MIF Management Request
1. On each sub-prod, e.g. DEV and TEST, go to Multi-Instance Management > Manager Instances.
   NOTE: If you do not see it in navigation type sn_mif_managed_by_instance.list in the left-hand nav and press enter.
2. Open the Approval Requested record pointing to PROD  with the little “I” icon and use the Approve Manager Instance button on the form.
   
   

Step 3: Controller Environment (PROD)

Deployment Instances define all of the environments that will participate in deployments from dev to prod and link them to their associated MIF definition. It also authorizes the activities that the ReleaseOps application can perform in each environment. 

1.  Go to ReleaseOps > Deployment Instance and add a new record for each instance (DEV, TEST and PROD) pointing to the MIF instance record created earlier.

   

2. Configure ReleaseOps Pipelines
   There are two sample pipelines that come out of the box. A Pipeline Instance record will be added, linking the matching Deployment Instance to that Pipeline so it knows where to send the code for the interim steps of the pipeline.
1. Go to ReleaseOps > Pipelines
2. For each of the sample pipelines, Sample On Demand Pipeline and Sample Release Pipeline, open the record and use New on the "Pipeline Instances" related list.
   
3. Select the "Test" Deployment Instance created earlier and apply the label "Test".  This is an abstraction so that the ReleaseOps Playbooks know which environment is the Test environment without having to directly reference your specific instance name.  For example, you may later add a label for “QA” or “Stage”.
   
   

Step 4: Update Sources in Controller (PROD) and Test (TEST)

MIF is used to coordinate the process, but at this time it does not actually move the update sets.  For that you will need to use the traditional Update Sources (aka Remote Instances) to link environments.  

Notice that there is a link from Prod directly to Dev (used by Deployment Analyzer), which is atypical and you may need to add this link yourself.

You may already have Update Sources defined for transferring update sets between instances. If so, congratulations! Please confirm that you have valid update sources defined in PROD and DEV matching the following instructions (and the graphic above).  Check the documentation on Update Sources for more details.

1. Configure Update Sources in PROD
   Navigate to System Update Sets > Update Sources and create the following configuration:
   
   1. 1. Type: Development, URL: {url for dev}, Credentials, Short Description: "Dev Update Source for Deployment Analyzer"
      2. Type: Test, URL: {url for test}, Credentials, Short Description: "Test Environment Update Source"
2. Configure Update Source in TEST
1. Navigate to System Update Sets > Update Sources and create the following configuration:
2. Type: Development, URL: {url for dev}, Credentials

Step 5: System Property (DEV)

In DEV go to System Properties and set the property sn_releaseops.deployment_controller to the deployment controller's base PROD URL. This is how the Deployment Request is created with a button from the update set in dev.

That’s it.  Follow the steps from this linked demo to create and test your first deployment:

https://sn.works/releaseops/vids/demo