Yesterday, we announced our series B funding with IVP, Google, and ServiceNow all contributing to the round.
As you might expect, Google and ServiceNow both play critical roles in CI/CD, specifically around cloud/container orchestration and change management.
Back in January, Harness announced integration for Atlassian Jira to help dev teams automate the ticketing/auditing of deployments and approval of pipeline stages. Today, we're extremely happy to announce the same support for ServiceNow.
In a typical enterprise, we're seeing that Jira tends to be the system of record for dev teams (pre-production), and ServiceNow is the system record for IT Ops (production).
For Continuous Delivery to scale in these enterprises, Harness needed to support both systems of record so that change can be streamlined and automated across all teams, environments, and systems.
Harness ServiceNow support enables two key use cases:
1. Track/audit the progress of production deployments (and pipelines) using ServiceNow tickets.
2. Approve/reject deployment pipeline stages or workflows using ServiceNow tickets.
Here's a quick 3-minute primer on the new integration:
Harness can manage multiple instances of ServiceNow and has complete role-based access control (RBAC) for separation of duties.
It takes just a few minutes to integrate it into your deployment pipelines.
Go to: Setup > Connectors > Collaboration Providers > + Add Collaboration Provider
Harness now gives you the ability to create or update a ticket as many times as you want during the execution of a pipeline, stage, or deployment workflow.
For example, let’s edit an existing deployment workflow in Harness so we create a ticket when our deployment workflow execution starts, and update the same ticket when that workflow successfully completes.
To do this, let’s open and edit an existing deployment workflow, and add ServiceNow tasks to our pre-deployment and post-deployment steps:
To create a ticket, we simply configure the pre-deployment step as follows:
Notice we can use Harness variables (using $ pre-fix) to populate tickets with workflow, artifact, and pipeline context.
We can also create a new variable called “snow” from the output, so we can reference the same ServiceNow ticket again in our workflow should we want to make updates.
To update the same ServiceNow ticket, we can configure a post-deployment step in our deployment workflow as follows:
Notice we use the variable ${snow.issueNumber} as a key to reference the same ServiceNow ticket we created in our pre-deployment step. This means we can incrementally add activity to the same ServiceNow ticket without needing to remember ticket ids or identifiers.
Now, when we next run our deployment workflow, we see our ServiceNow steps fully visualized (screenshot below) with context. Notice the deep-link to the ServiceNow ticket we’ve just created in the bottom right of the screenshot:
Clicking on the deep-link shown in the above deployment workflow takes us directly to the ServiceNow ticket, and reveals all the activity we logged during the pre-deployment and post-deployment steps:
So there you have it: full progress tracking of your deployment pipeline in a single ServiceNow ticket!
Now on to the second use case...
Up until now, our customers could only approve/reject pipeline stages or workflow execution using big shiny buttons in our Harness UI:
or using Jira (which is slightly annoying if you run ServiceNow).
Today, customers can now do all this inside a ServiceNow ticket by simply updating the value of a pre-defined ServiceNow ticket attribute.
For example, changing the State attribute of a ServiceNow ticket to “Resolved” or “Approved” could automatically approve the execution of a pipeline stage or deployment workflow in Harness.
Again, this literally takes a few minutes to configure and you’re all good to go.
Let’s imagine we have a simple 3-stage deployment pipeline consisting of Development, QA, and Production.
Now, let’s imagine we want a new ServiceNow approval stage to govern how code is promoted from QA to production.
Click on the “+” symbol in-between the QA and Production stage. Now, let’s define what our ServiceNow approval criteria should look like:
Select the ServiceNow instance and Ticket Type (Incident, Change, or Problem).
Lastly, define the ticket Issue Number which will approve/reject your pipeline stage (you can use your snow pipeline session variable).
In the example above, changing the ticket Status to Done will approve the pipeline stage and changing the ticket Status to To Do will reject the pipeline stage.
Once our Approval is configured, our pipeline now has 4 stages:
And there we go: in just 5-10 minutes, you can fully audit Harness deployment pipelines in ServiceNow. And, you can also use ServiceNow to drive pipeline stage approvals.
Want to try Harness? You’re 2 minutes away from getting started with our trial.
Cheers,
Steve.
@BurtonSays