hello and welcome to our video series on adopting servicenow's devops change velocity application in this video we're going to be reviewing the adoption journey that customers tend to take in order to gain value throughout the entire adoption process for a quick review devops change velocity provides visibility and automation into your change process it does this by connecting the tools that your development teams are already using into servicenow into our devops data model this allows us to automate the change process by adopting policies that can leverage that data in order to answer questions like have all of our test cases passed are our security scans have they all run are there any open incidents all of those are questions that can be asked by bringing in data from your development tool chain it also allows us to gain visibility into your change records themselves as well as measure the performance gains that your teams are having as they adopt devops now as customers adopt the devops change velocity application it's typically something that's taken as a journey and while the ultimate goal is to automate the change process in such a way that you get the speed of a standard change while gaining the benefits of risk reduction that you gain from a normal change this is something that customers will adopt over time now it tends to start by connecting the tools that your teams are leveraging in order to gain insight into the data that they are producing the next step is to connect the devops data to your change requests so that you can get visibility into the change without changing your process the next stage tends to be registering the changes so that we can gain a more uniform and correct set of data applied to the change requests without the development team spending large amounts of time on the change request creation process and again ultimately this leads to being able to define policies that look at the data to provide a quantitative reduction in risk while gaining the same speeds that teams would get if they were using a standard change so next let's go over how this adoption journey looks now the first step again is to onboard your tools and your teams and this is done via catalog items the reason this is important is that there's a lot of data that we're going to be collecting this data comes from what we refer to as your tools those tools are things like your instances of jira whether they're in the cloud or on-prem into github or git lab into your jenkins pipelines into quality scanning tools like sonar cube or into tools that do most of these like azure devops these tools have data in the records that we create this allows us to have the plans that contain your epics and stories the repositories that contain the code commits and the pipelines that are creating your builds and artifacts and are running test cases these are then linked into what we refer to as apps so that you can know for instance with the parts unlimited application what are the plans repos and pipelines that this team is leveraging so that we're able to give better insights into how that application is functioning so let's jump into service now and see how that works now let's begin by navigating to a service catalog that i've published into this service portal i'm going to go to request something and then we're going to begin by connecting our tools to our servicenow instance so i'm going to choose the devops tool onboarding catalog item first we're going to name this tool that we're connecting to we also are going to specify what tool we're integrating with next we'll specify the url to this jr instance provide a username and an access token that's used for servicenow to be able to communicate with your jira instance now there are two additional questions that are at the bottom do you wish to configure a web hook or do you wish to use a mid server now by default servicenow will nightly poll for data within your jira instance if you want to have near real-time access to the data then you would also need to configure a web hook in jira servicenow can do this automatically however it typically requires elevated privileges and you'll need to work with your jira admin in order to set that up i'm going to leave this off for now the other option is for using a mid server this is needed if you are running something like jira data center within your firewall that does not have access to the public internet so a mid server is used in order to connect to that jira server that is going to be behind your firewall so we can still get access to that information again you would work with your servicenow admin if a mid server is needed the next thing to do is to click submit and do this for github and for jenkins as well as any other tool that we need to set up but that should be enough for this demonstration we're then going to navigate again to our catalog item but this time we're going to connect all of those tools to the apps that we're going to be managing so let's select the devops app onboarding once on the devops app onboarding catalog item we're going to set up a new app for globex we're going to choose the pipeline that we're going to be connecting to the server in this case for jenkins and select which pipelines we're going to use we're going to use the web we'll also connect the corp site if you have multiple ci cd pipelines set up then we will be bringing all of those together we'll also be given the opportunity to import pipelines that have been run in the past so that we can go ahead and prime the data within servicenow so maybe we'll go back to the beginning of may and do this through today we'll do the same thing for github and finally for jira next we'll click the submit button and after that your teams have been set up to where we can capture the data from your tools and it's connected to an app that is going to be managed within servicenow change traceability allows us to gain insight into what's going into the change request without changing your existing process now let's begin by creating a new change request i'm going to navigate to my change requests and create a new change we're going to create a normal change now let's give this change request a name and we're going to select that this is a devops change by selecting that this is a devops change we now have the ability to add devops data to this change request there are three ways that we can associate this data to the change request either from the release version from tools like jira the build number from jenkins or the artifact version which could come from jenkins as well as tools like artifactory i'm going to select the artifact version that we're going to be deploying so for this artifact version and we're going to be releasing 1.5 of the globex war and if there are more artifacts if this was going to be a package of multiple things that are going to be deployed you would select additional artifacts here we're just going to choose this one for today now we get a picture of what information we're going to see once we create this change request there was a single work item in this case uh this could be a story that the web page content is incorrect we'll also be able to see the code commits the results of our tests the version of artifact that is going out as well as any software quality scans that were run by clicking the submit button we will attach this devops data to the new change request now let's go ahead and save now the rest of your change requests would need to be filled out based on your existing change processes however as we scroll down to the bottom we can see the devops related lists the bottom that tells us things like the work items the code commits the test summaries software quality scans and the artifacts that are being deployed this information is typically manually added to change descriptions but now we have this information directly on the change request and if we need additional information we can click into it to get additional details so now i can see the results of the software quality scan to understand how many lines of code its maintainability the code coverage any vulnerabilities or bugs that were discovered as a part of a scan from sonar cube this allows the change team visibility into what goes into this change request without the development team spending time pulling data from all of these tools and populating it manually and in an error-prone way into the description of the change request going back to our initial adoption journey if we begin with onboarding the tools and getting to change traceability at this point without any modification of your existing processes or a heavy a lift on setting up these tools we will allow you to get visibility into the data connected to your changes which in and of itself is a huge benefit for your change teams the next steps move from gaining visibility into automating this process as we move beyond visibility into the development data on your change requests we now move into involving the development teams on automating this process we'll begin with automating the change registration process which will allow our change requests to be automatically created and the data on them filled out in a consistent manner each time the change request is raised so let's see what this looks like we're now looking at a change request that was raised a part of the development team's ci cd pipeline this will create a name by default fill in description include any additional information which can include things like within the risk and impact analysis data that comes from the development tools so we can know about any active incidents any work items any of the results we need from sonar cube all of this will be a part of the change request and filled in again in a repeatable process that's not to say that we don't have access to the related lists we saw earlier we do this just allows the change request to be filled out in a consistent manner by each of your teams automatically as a part of their ci cd process so let's see what the development teams did in order to automate this change process in this example i'm using a jenkins pipeline that is defined via a jenkins file this jenkins file is maintained in github as we can see we have a pipeline that has multiple stages the last stage in this process will be doing a deployment which has two additional functions that have been added into this jenkins file these are provided by the servicenow jenkins plugin that is freely available and on the jenkins store the first function will register a package so that we know about the artifact that's being deployed and the second one will raise the change request but how do we know what data is going to be on that change request when i navigate back into servicenow i'm able to see the pipeline that was defined in jenkins with all the steps that were included i can then navigate into the deployment step that was defined where i can see i have a couple of options one is is this step under change control and the second and importantly is this going to be a change receipt the difference between the receipt option being checked or not is that if the change receipt is checked we will not hold the pipeline waiting for the authorization of this change request we will simply create the change request we then will fill out information from that change request and fill in information for instance like the configuration item we'll know the change approval group and you can also use a template that will pre-fill in the rest of the information that is needed for this particular change each team could have a different template however they are typically reused across multiple teams based on the type of change that is being raised once this is set the change is automatically created the pipeline is not held and the change team has a consistent view of information that is tied to this particular change request the last step in this process is to move to full change automation this is where we leverage the data not only for visibility and consistency but also for connecting this to policies that are defined within servicenow to allow the authorization of the change to be completed as well let's take a look at that pipeline step that we were on just a moment ago right now this is set to change registration only by selecting the change receipt option the first thing we need to do is deactivate the change receipt at that point instead of the change request being created and then returning immediately the pipelines control to continue we will now hold this change until it reaches the implementation state if we were to look back at the change request we saw earlier you'll notice that it's currently on the authorized step we will hold the change until this particular change request is authorized and the level of automation is really up to you so how do we automate this well the first thing we need to do is define policies those are a standard part of servicenow's change management application it can be found under the change navigation item scrolling down until we get to change policies and we have two things approval definitions and the approval policies let's view the approval policies there are several policies that have been defined we're going to take a look at the devops approval policy now policies have two key aspects to them they have the policy inputs and the decisions inputs allow us to connect data from the devops data model or from any other source within servicenow to be evaluated for the decisions themselves we can look at things like if there are any outages we can look at any security vulnerabilities that may have been discovered whether or not you have any error budget remaining whether or not this is a critical service or a low criticality service we can look at any information that resides within servicenow those policies are then used in decisions decisions allow us to choose what level of automation we want to achieve and each decision has an outcome of what we want to happen we can have a change auto reject we can have a change auto approve but we can also send things for manual approval this could be for highly critical services or this could be something where we have a good amount of data but we want some eyes to review it just in case that could be something like 98 percent of our test cases are passing and we only do an automatic change if 100 of test cases are passing 98 is still good but since it's not 100 we want people to review it just in case if we look at this example of all devops policies are met we can see what that criteria looks like and all we have to do is use the standard condition builder in order to decide what criteria is necessary in order to approve this change automatically if this matches then we will have an auto approved devops change if it is not selected then one of the other options like an auto rejection or the manual approval will also be used there's no limit to the number of policies that you can define within your company the policies themselves are used within a flow that is defined for your company just like any other change workflow that you would be leveraging we have an example change workflow that will wait for the change to be approved and it will make that approval via the decision table that says what information we use in order to understand whether or not we have met all the criteria that is necessary we leverage that data in order to decide what the outcome is again things like it's auto approved or auto rejected or sent for manual approval will all be a part of your workflow we'll then wait and if the change is rejected we will notify the pipeline that the development team is run that this change was rejected stopping the pipeline and giving information back to the development team on why their pipeline and why their change was rejected if not it will wait until we have reached a maintenance window for the change to move to the implementation state once the change moves to the implementation state we will signal back to the pipeline that it is safe to continue and deploy that artifact into production once the change is authorized it will move into the schedule state where again it will wait until we've reached the window for deploying the change before signaling back to move into implementation once the implementation is completed by your pipeline it will move to the review state where it will hold waiting for your team to review the deployment and ensure that it has been successful with many organizations that we've worked with this has turned a process that can take days or even a week into something that generally takes a few minutes to run through the process and now you've seen how companies like yours can get started with servicenow's devops change velocity to get to full change automation but while automating changes is the ultimate goal we have been investing in reducing your time to value by making it easy to connect your devops data to your changes through change traceability to get started all you need to do is activate the devops change velocity application and connect your tools to servicenow like we saw earlier in the video with that i'd like to thank you for watching this video on how to adopt servicenow's devops change velocity there are additional videos that go into more detail as to how you will get started with each tool integration what's necessary in order to accomplish the tool connections if you have additional questions please feel free to reach out to your servicenow team in order to provide more details thank you