thank you everyone for joining uh my name is colin o'brien i am a part of the product management team for our devops solutions here within itsm servicenow and today we have this webinar scheduled for how we can help you kind of accelerate innovation by connecting your devops tools to service now so as a part of today's presentation i'll be the one primarily driving for today uh however we also have uh two people on my team uh isaac bartz and joe offenberg that will be monitoring the q a so as questions come in please use the q a panel uh we'll we'll also monitor the chat but i believe the q and a's get captured um better and we can follow up if need be so as you're asking things they'll be answering or they'll will be interrupting me for something that would be good for kind of the broader audience to hear so again feel free to keep this interactive if you have questions ask them through the q a panel alright so for the uh for the webinar today i don't have any plans to go over anything that is forward-looking however just to keep the lawyers happy we're going to make sure that everyone knows that if there are any forward-looking statements they are based on uh plans and not to make uh any any decisions based on things in the future for today and also we have uh more webinars coming up so in the chat there should be uh links that that will allow you to register for more of our events so definitely as as we're going through this please please use that to find out all the other events that we have going on all right so uh for today i kind of have three things at a high level that we're going to be going over for today uh first is an overview the devops product uh and i've been with this product line since the beginning um that has been renamed from originally just called devops to devops change velocity and for you know many of our itsm customers today they are not aware of how this solution was designed what it's supposed to do so i'm going to give a brief overview of that but the the bulk of today is going to be how the journey looks for you to adopt devops change velocity within your organization um and we'll be going through uh you know really how to get started and we'll be walking through you know exactly what it takes to get going through this entire journey uh because it is it is something that is meant to be adopted over time so you will add more and more to the automation capabilities based on your needs based on where you are in your devops journey and where you are in your automation journey so why did we really get into this space within servicenow why don't we start working on this uh you know several years ago and what we found as we were working with customers especially within the enterprise is that it it can be very hard to scale devops within enterprises adopting devops within individual teams or within groups of teams is i'm not going to say it's easy it's it's definitely not it takes work but as it really broadens to the rest of the organization it can get really hard and it leads to a variety of issues the ones that we were hearing the most is that there's really that lack of visibility and traceability you know teams all are setting up their own tools so different teams are using different tools or even when they're using the same tools they have lots of of instances of it that don't know about each other that don't talk to each other and so there's you know lack of visibility which makes it difficult to kind of share anything between the development teams especially the operations teams that are going to be consuming this this data and because of that sprawl of all of these tools that the teams are implementing it makes compliance you know harder i was working with a customer very early on that would spend you know person week several person weeks just pulling together everything when any kind of compliance you know went through uh so they were they're spending about three to six weeks depending on team just in adhering to these compliance checks um and that's that's because again it's sprawled all over the place and then it also we found that the actual delivery time wasn't getting a whole lot better the development teams were building faster they were building more repeatably but because of you know the prior two issues there was still a long lead time from when you know the the new versions of their products are ready you know when the development teams and uh implementation teams are ready to when things are actually going to go out into production so while building products was becoming far more repeatable the actual time to deliver it was not decreasing you know significantly so this has caused challenge across a lot of different uh personas you know development teams in my my background uh i i've been a developer i have lots of friends that are still developers and they are really just like you know spending time with more of the administrative tasks tracking people down in order to get approvals uh they want to be you know doing what they they love to do which is you know building stuff uh and they want to spend more time doing that you know the the higher level like vps of appdev they don't have a good handle across you know their end-to-end teams and different teams using different tools there's a really a lack of visibility across the value stream the change team they are under pressure to deliver more and faster however they're still being held to the same compliance requirements that exist today so they still have the same regulatory concerns but now they're asked to do far more than what they ever have in the past uh we actually had one customer that you know told us that as they were wanting to help get things out faster they're like you know there's four of us and 400 of them um and we can't meet the scale that they need operations has issues because there's still that lack of visibility they don't know what's going to be running in production and from a compliance a governance officer when everything's spread out they're not sure that we are actually meeting whatever you know sometimes legal requirements that we have to adhere to before we deploy any of this into a production for customer use so what we have been working on is how do we how do we fix those things how do we help fix this problem and we focused on well how do we help the developers not spend a whole lot of time trying to flag down people for changes uh going to cab meetings when the data is already there they've already done this work but you know the change team isn't aware of it uh for you know those vps of app dev how do we give visibility across the value stream across all of their teams with the change team how do we help them to scale instead of having to review changes how do they help the teams to understand what you know those requirements are and just help the teams that are needed and really you know automate ultimately that change process for when things are going right for operations they will have a faster ability for turning around you know uh resolutions to incidents so mttr going down because they have a full picture of what it is that they are supporting and then obviously from a governance perspective we're able to pull and collate all of this data together so that when audits take place it's not just that they're faster but we have a far higher confidence that they have all been met all of our policies have been met because we've just been doing it as a part of our general process so let's talk briefly about what it is that servicenow actually uh built so we refer to it as devops change velocity or devops change automation you'll you'll sometimes hear automation and velocity uh swapped around but ultimately it's about working with the tools that your teams have in order to solve those problems that we just went over so we will connect to your development team's tools like jira and github and jenkins and bitbucket and azure devops and git lab and a host of others pull and pull relevant amount of information from those tools into servicenow so that allows the teams to continue to use the tools that they are using but servicenow has you know i'll call it the the metadata about this so we'll know about the stories that they're working on we'll know about the code commits that have gone into modifying these products we'll know about the builds and the tests and the security scans and not only will we know about them we will have them all connected so that it's not just that we know about the story and the code commits but we'll know what code commits were attached to which stories we'll know the test results of the build that is going out into production and what all the code that it was was uh was connected to that and therefore the stories that we are actually deploying so it's connecting it and creating traceability around all these uh all these records all these artifacts that are coming from different tools and generally don't know too much about each other now how does that become interesting well visibility is interesting into itself and we're going to show how you can start with just getting visibility into all of this data that's spread out across all these tools but the next step comes when we want to automate that process so oftentimes i'll work with customers and they'll have change policy documents that will say you know in order to go out we need to make sure that all stories have been accepted by the product owner that the tests like our unit tests are at 100 passing that security scans have been run there are no you know large vulnerabilities within what we're deploying and all those are spelled out in a word document well instead why don't we just have in servicenow an automated system that looks at the data and makes that decision automatically to say did you follow the policies that we have in order to deploy to production so now we can take this connected data and make that decision automatically instead of having people spend time when you've met all your criteria and this is a couple of examples that we've we've used with customers about bills being successful that there aren't the open incidents that your tests are passing that we're not in a maintenance window or sorry that we would be in a maintenance window we're not in a blackout window in order to say whether or not we authorize this change and then also helping to really see across that value chain that how are we doing so are we getting better are we getting faster are we becoming more reliable which are all of the goals that devops teams strive to reach by measuring what's going on across all of these tools so uh we again have worked with lots of teams at this point to integrate these tools into servicenow and automate their change process so that we are reducing manual activity wherever possible we're able to increase that throughput and we're able to make sure that we're doing it while at the same time adhering to the governance requirements so you basically get the best world especially the best of both worlds especially in the governance area where we both have the compliance but without the overhead that typically comes in when people are going through and doing all of that manually and it's an example of one of our one of our customers that we worked with early on they were spending you know lots of time on just tracking down people for the change but you'll see that their lead time was usually at least one week so this was actually one of the better customers that i had been working with most were close to a two-week period of lead time from when development was done to when something could actually go out somewhere as long as a month um but they were about one week and it just turned into next available so we had eliminated the time it took to create changes we eliminated the time it took to find the people for approval we eliminated the amount of time development was spending with handovers operations and moved deployment lead time from a week to just when's our next window that's open and then the actual time spent approving became effectively automated and those are the kinds of results that we are seeing with most of our customers that we have been working with as they have been automating their change process in this way so i said at the beginning that this is a journey doing full change automation is the end goal where you're having all of your policies evaluated by servicenow however getting there isn't something where you have to do it all in one kind of one implementation where you're just going from we haven't automated a thing to we're fully automated it really has this journey and this is the journey that i'm going to be walking through for today which is uh how do we get our our teams and our tools onboarded what does it take to do that setup and i'm going to be actually doing a i'm going to be walking through that process for today then we get to change traceability now if you have been like if you're if you're one of our customers that's been working with us for the past several years uh the change automation at the end is what you are used to but we came out with new capabilities early this year with san diego that we're going to be highlighting in this webinar today which is how do we provide visibility without changing your process you know i would say is i've worked with a lot of customers both during our early adoption phase all the way through until we became a ga product and for the years after that and getting to full automation usually took a good bit of time not in doing any kind of implementation and service now there is definitely things to do in servicenow to fully implement it but most of the time was on whiteboards uh defining what that process should be when you remove people and add machines that are going to be evaluating this so almost every customer that i worked with spent time saying let's not just add our policies let's really look at what our process should be and and and basically implement that new process for our devops teams so we wanted to have something that you could get started without doing that and that's change traceability where you're able to connect what your development teams are doing to change requests to increase visibility without having to change any of your processes without having to change anything about your change management uh setup and i would i would honestly say that as we're going through this that is something that's all done through the ui and it's something that you could get started with even today after we get done with this webinar that was the goal that's why we put this together is that you can do this without really bringing in any kind of implementation help and then the next step after that after change traceability we refer to as change registration this is where we start our automation of the change process by creating the change requests in a repeatable fashion with the data that is needed um automatically so this doesn't automatically authorize the change but it automatically creates the change and this came from working with customers where when we started digging into it the amount of information captured on the change varied a lot from team to team because not every team knew what should be on their change requests so change registration makes it a repeatable process it's where we have the right data and we have the same visibility but without going to full automation of your uh change process that's the fourth step automating the authorization process really automating the change process so that people are only involved as an exception case when your policies aren't met and you need people to get involved but if everything is going as it should people aren't needed in order to do that change uh that change process and that's the ultimate goal where we uh you know decrease the risk we increase the the success rate because we have a fully repeatable process where we have data that is always evaluating whether or not we have done what is necessary in order to get those changes out the door so with that we're going to go into that adoption journey and i'm going to take this in phases so the first thing that we're going to do is go through the tool and team onboarding process now there is a one-time setup that your admins have to do and that is setting up a credential for for what we call the create devops tool i will show you what that is uh and that is simply necessary so that we can automate the onboarding of your tools and of your teams through these catalog items that allow us to just ask information like what is the tool where does it live what are the credentials and then we do the rest of the setup so with that let me switch to my instance and start going through uh how we do that initial setup all right so i am okay yes there are some questions on the on the chat do you think this is a good time to quickly take them oh certainly yep yeah i'll ask the first maybe as i call joe can ask the other one so there was a question asked around as you were showing the list of tools there was a question asked around are aws build processes or pipelines supported so we have a partner that has implemented an integration with aws code pipelines i believe that's what they're called lots of tools out there so we have uh we have a couple of customers that are using that and the partner actually releases their integrations open source so the partner is rapdev and as follow-up especially if that's in the q a then we should have captured who did it otherwise as follow-up we can send you a link to that integration which brings up a quick point i want to make there are lots of tools out there we built a framework for how to integrate tools with servicenow if we don't have an out of the box integration we have really taken care of most of the plumbing where you simply have to think of it like a transform where you have to take whatever data they send to us through web hooks so web hooks are the technical how external tools send data to servicenow but we just need to transform what they send to us into the json format and if json isn't uh it's json that's a new term for you it's a common format much like xml uh that that is used for moving data between tools we need it in a certain format that is documented on our um on our documentation site within servicenow we need it to look a certain way so you perform the transform that's it the rest of it is taken care of by us the endpoint management is taken care of by us uh the how you do connections and credentials are handled by us we just need that transform in order to put the data that they send us into the right tables you don't even have to know our table structure just the json format so again rapdev has built an integration with aws code pipelines and we will send that link as a follow-up today awesome thank you yeah colin we also have another question here might ask for some more information but the question is can we talk about the google cloud platform build process yeah so we may need a little bit of additional information but we typically don't you can use google you can use gcp you can use azure devops as your your compute platform and from our perspective we do not care what the tool like what what your your cloud platform is we are connecting more of your your development tools to us so if there's like if there's some specific testing related data as an example uh then that may be something that we look into but i'll probably need a little bit more clarification for gcp specifically um because again if you're using azure aws or gcp we work with them we don't really need to know what your underlying infrastructure system is are there any any other questions before i continue uh let's continue okay perfect uh so we'll come back to insights uh toward the end it's just uh the dashboard that i tend to land with uh but let us begin with the connection and credential that i said is a one-time setup and this is something that your servicenow admin has to set up so within uh within servicenow there is something referred to as connection and credential aliases and connection and credential aliases basically are storing what it sounds like we need to know your servicenow instance and we need to have a user that basically is authorized to be able to create records um and this is documented on again on our website but there is one that will be there when you install uh servicenow devops when you install devops change velocity this particular record which is called create devops tool will be there but what won't be there is at the bottom there is a connection that has to be created where you will specify where it is so i'm i'm on this this vsm demo one instance so i have to to put that and we also have to specify a credential which basically is i have a login that i'm using and a password that that i have as well and that is used again to automate the tool creation process so that we can do it through catalog items which greatly simplifies the process um and and so again that that is a one-time setup that your admin has to do everything else will happen as you want to onboard a new tool or as you're wanting to add a new app to being something that you manage through this process so let's go into how you will actually connect a new tool to servicenow so first of all we can go to a service catalog so i have just placed these two catalog items on the regular service catalog when you are working with your team as to where it should go you can place it in whatever location just kind of makes sense i i placed it here because it would be very quick for me to show from a a demo perspective but if especially if you're using like service portal it might make sense to have the catalogs listed there and these catalogs there are two of them two catalog items one is devops tool onboarding the other is devops app onboarding so tool onboarding is what you do first because you need we need to know about the tools before we can connect that data to your apps that that you're going to be managing so you'll click on tool onboarding and this is something that again depending on your organization and what their level of comfort is with your teams creating this most of our customers that we are working with allow the teams to do this setup and that's because the teams already know about the tools that they're using now you can have because it is a catalog item you can have a process where it needs to be reviewed and approved by someone uh within the development organization or someone within your servicenow organization i have it set up to where it would auto create it but all this basically is is giving things a name so this would be for instance uh collins adio instance um may not be the best name i'm just gonna use it for now and then we need to know what kind of tool we are integrating with so whether or not it is an out of the box tool or whether it is something that was created by a partner or by yourselves because customers can certainly build these the vibrations we intentionally designed it to be straightforward enough that it doesn't require a partner if you are are handy with doing uh integrations but it will show up in this list so this is the list of all the integrations that i currently have installed this is not the list of all tools that we support we have a lot of tools between our store and lab where you can have a pretty long list i just like to keep mine short to just the ones that are commonly used so for instance i could choose azure devops that's what i i selected for today that's what i typed at least in the name and then we need to know the url and the user name and the access token so the url for instance in this case would be move my zoom window out of the way it's going to be this particular bit of azure devops so i would have this here and then i would specify that that is the url to to the tool in that case it's a project that i am working on and then we need a username usually this will be a system user uh i would just type in for instance mine at servicenow.com and then i would have a personal access token that i would put in here i'm just going to type something cause i'm not going to create things just the interest of time so i would have an access token that that azure devops would be supplying for me and then we have two options down here at the bottom one is do you wish to configure web hooks for the tool and the other is mid server i'm going to actually start with mid server because this is a very quick answer if you are using a tool like let's say jenkins that is housed within your network and has no external access so that servicenow couldn't directly talk to it then you'll need a mid server um if this is and i've had customers where it has been installed within their network but it is externally accessible so they didn't need to be on vpn or anything else to access it then you don't need a mid server because we can directly connect to the tool so if you're able to connect to it without being on your company network then you don't need this but this will be the inner this will be the go between for the times and jenkins is probably the most common tool that needs a mid server setup that you would need to select this box so that we can know to communicate through a mid server it is common and this is probably the number one uh pitfall that i see when customers are needing to set up a mid server if this has been pretty common there is a good chance you already have some mid servers set up within your instance today uh however it is also a pretty good chance that they those mid servers also cannot see the subnet that is set up for your development tools so you will need to make sure that the mid server that you work with can actually see the devops tools that your teams are using i've seen that as probably the number one uh issue that has come up when a customer set this up and it says hey it's not working or this actually happened to me it's working sometimes because some of the mid servers could see it and others couldn't it is because of where the mid server is and whether or not it can see your tools so if you are running your own hosted versions be aware with mid server setup you will need one and you will need to make sure that it can see your tools azure devops is in the cloud so i would not select that for uh for today now the other option that pops up and this if you were really paying more attention than i would expect because i wouldn't have probably noticed this myself this did not show up by default it showed up when i selected azure devops for some tools that would be jira jenkins github and azure devops we can communicate with them instead of with web hooks we can just directly you know ask them for data periodically and that is to help with the onboarding process setting up web hooks tends to need admins of the other tools that you're talking to and getting credentials is usually one of the hardest things to do within an organization so by not needing web hooks you can actually circumvent that process and and servicenow will just periodically grab data from these tools when it's needed usually it's on a on a nightly basis where we just collect the data from those tools instead of it being in a real time uh in a real-time fashion so if i do not check this box then that's all i need in order to connect to azure devops i need to give it a good name i need to say that it's azure devops i'm working with i need to specify the url and then i need a username and usually it's an access token not a password which your development teams especially again if you if you allow them to and i do recommend that you allow them to be able to set this up they will know that information so they won't have to go somewhere else in order to complete this step after that they hit order now and that creates the tool that's that's all that's needed for getting tools connected so i uh i don't see on the q a anything pop up but are there were there any questions that came up um uh related to tool onboarding before i do the app onboarding which will be next none can none column uh keep going please okay so that's connecting the tools the next is how we onboard uh the apps themselves that you're going to be running through the change process uh now uh just keep in mind you would need to do that for each tool that your teams are working with so if they're working with azure devops and jira they would need to do that twice once for jira once for azure devops if they're using jira jenkins and github you do it three times one for each of them so that's just something to keep in mind because as i go through the app onboarding it's going to uh it's going to need to know that you have already set up those those tools to go further so with app onboarding we have two things that we can do one if we already have an app that we're working with then i can make updates to it so let's say the team has added a new pipeline or they've added a new git repo that they're storing some code in then they're going to be making updates so we have add to existing then we have create new which is what your teams will be doing at first so we will have to give this a name so i am really not um not creative so some new app that is my app name it was either as a coin toss between some new app and collins app that's that's my level of creativity and then we have uh next about onboarding pipelines repositories and plans and this is where the tools come in because when i look at for instance pipelines what i'm looking at is which tool have i been working with we had several that were set up ahead of time with azure devops with jenkins with github through github actions and i'm just going to for now select um uh this joe github jo github and that now gives me additional i guess that was not the right one what was the one that i used yesterday let's spin that one there we go so it's number two so now i can see what were the pipelines that this instance of jenkins is managing uh and if i'm working with the globex uh site then i have three pipelines and i can add them to be what are the pipelines that my team uses and you can filter down through search so um you know as i'm typing this in it will filter out the ones because oftentimes you'll have many in this list your teams will know their names so again a team would go in and say that this is available and then we can import to bring historical data in and then do the exact same thing with your repositories so if i have uh if i'm using you know github or maybe i'm using actually a an azure repo i can use that in order to kind of change what it is that i am looking at to look at all of the the repos that are available you know select the ones that i have and add them and then finally we would do the same thing for onboarding plans which will ask what uh what tool to use for planning i have several here i've got another parts unlimited i've got some jira and by selecting that it's going to show me the plans that i can also add now what this does is if i go to my devops apps and again i'm going to be not creating just in the interest of time this will create an app which will have um all the associations related to it so this app knows about what are the uh what are the plans the repositories i've got a git repository i've got two pipelines that are being used if you're also using something like artifactory then we can see which artifact repos that are being used because we're trying to connect all of this data now what does again connecting all this data do so going back to the traceability this allows you to raise a change request that has all of that data associated with it so let's real quickly create a new change request so this is just going to be a normal change request not going to do anything anything really fancy but this change request that i'm going to create i'm going to say that it is a devops change this is a new version of collins app and oftentimes i find that in the description field you will have you know the what are the um what are the the stories that are going to be going out what are the test results that are going to be going out instead of typing all of that in we have this option for add devops data that will show up that will allow us to connect the information from those tools to our change request so i'm going to choose we have three different things you can choose from release version is basically pulling in from your planning tool to say that here is um you know for this particular release here is all the data that we are going to be looking at and when i click next it's going to show me all of the things that we found as a part of that release version so we have a single uh work item i can see any code commits any test summaries any software quality scans all of that will be added so that when you submit it it's now attached to this change request i'm just going to save it and you will see it at the bottom of our of our change record so we are able to show so for instance this actually has some config data uh it's got some stories any of the information that we were capturing as a part of that change is now going to be here at the bottom instead of your teams having to type it all out so that is going to allow us to have an increase in visibility on the change by simply collecting data from your tools and again if you get nothing else if if you decide i'm going to drop from the webinar right now which you know don't we have 15 minutes left got two more things to show then and you just did that you will help to increase visibility to increase honestly the governance as well because all of it's connected to this change and you will be helping your teams to have a more repeatable process on what they are working on and how that is tied to your changes um and i have done that in the past a little over 15 minutes i think 20 minutes and that was also explaining what we were doing as we went in so we designed that first step to be very straightforward easy to do um all it really takes is knowing your tools and letting your teams do it your teams can provide that information so that when they raise changes they are able to attach the data without changing their process at all so real quick before i go into change registration i wanted to check to see if there were any questions on the uh q a about yes um we've got a great question here very timely for where you are in the demo uh the question from sean is how do devops apps map to csdm that is a good question so we generically refer to this as an app because we we every every term that we were using had some connotation to it that we didn't necessarily want to uh to override so we generally refer to things as apps what we found is that and i don't think i have any of these preset up with them but we have a link to business application which was the most common uh cmdb item that related to apps as we were working with customers so we have a direct link here now as an evolution is a part of csdm4 we have another field that's been added for this model id i'm not going to go into that deeply today other than it is explicitly for being compliant with the with csdm4 and with working through the business application the sdlc component uh and some other areas of csdm4 and how they relate to your products so most customers are using business app uh as the kind of generic what the the product is and the model ideas for future as more customers implement csdm v4 any any other questions that have come up in the q a yeah just one more and is it possible to create new cases with cli or api calls yes to both uh i would say api calls there are endpoints that servicenow uh provides for creating change requests we have so this this actually flows into the next part which is change registration where we have for the for some of the tools we need plugins others it just kind of works natively so with for instance jenkins and azure devops there we added plugins to make it easy so you don't even have to know about our rest apis but we definitely have rest apis for creating these changes uh and that's again what most most teams will either use those apis directly or will use these plugins to create their changes as a part of the process so in the interest of time i'm going to go through the change registration which this will allow teams to add a task into their pipeline to raise a change now what information should go on the change we have a variety of ways to do it and so let us move real quickly into that so i'm actually going to go into azure because it has a it has a way to see it visually easier than jenkins does and i'm going to edit this pipeline so i've already set up this pipeline to work with uh with servicenow and you'll notice i have in my pipeline this is a yaml pipeline so if you're not familiar with azure devops that's just how their pipelines are created we have a task that's called server change acceleration and if i click on settings it will show me what it is that we have to provide in order to raise that change request the top part mostly you ignore the interesting area is this bottom section here where it says change request details and by default it's empty by default you don't have to do anything other than that you want to raise a change request at this stage of your pipeline however you can add additional information that we will send over to the change request so if you want to have you know the requested by name filled in you can do that if you want to set the dates you can do that any of the fields on the change uh you would be able to specify in this this kind of json payload which you can actually copy it as a starting point and paste it in here and instead of starting and date i could have some other field that i want to add and this will be sent over to that change request so that when it is raised it will fill in this data so this is that that that next step in your automation where you will be filling in these change requests automatically now what that looks like is if i go to my i'm going to pull up a change let's just pull up what am i of course my changes all fell off so open change requests so what that looks like when it is raised is we have a uh a change that will be automatically raised and it will be filled in with data that comes from your ci cd tools so out of the box we will fill in we'll give it a name this can be configured to where you want it to say something else we will fill in your information about it and we can also fill in things dynamically so that if you want to know as a part of your analysis here are the results in text form then you will have all of that data here filling out back out plans test plans one of the first customers i worked with this on they i asked them to show me what a good change request looks like and their random sample of change requests that they clicked on most of them were not filled out correctly uh and nobody knew just nobody had noticed um so the first thing we did was turn this into a repeatable process where the development team didn't have to go and find all of this and fill it in it was simply filled in as a part of raising the change request and when it's raised in this way it will still show the connections that you have when you're doing visibility as well so we'll know the tests that were there we'll know which work items were there we'll know any software quality scans and what's going on with that so this raises the change request in an automated fashion without automating the authorization process that comes next so when you reach this step the key thing to know is what should our change request look like like what should it look like every time and then you will work with your development teams to add a step in their pipeline that raises the change request and either passes an information that's known to the uh only to your cicd pipeline or you can again you can use data from within servicenow to also fill out these results dynamically like this one where i'm looking at outages and incidents that was dynamically polled there is a flow that you can modify that will be able to look at any data and fill that in to your change request next step is the final one which is with change automation so are there any questions this is a pretty short step it's important because you need to know what should be on the change every time but all of this is built to the final piece which is change automation are there any questions on the q a for registering the change uh before i get into automating the change okay then i'm going to move on to the last bit which is the actual change automation itself so for this we're using capabilities that are in change management today called policies and policy inputs so let's look at our policies so i have a a policy um that i'm going to use that has inputs first so inputs are what is the information that we are going to evaluate what is it we need to know that'll usually be something like your percent passing of functional tests and percent passing of uh of our unit tests it could be how much error budget is remaining it could be how many security vulnerabilities are there this is an example you will define these and it's defined by just selecting a new button and giving it a name and a type so usually it's numbers but it can be other things like strings or even references for dot walking you'll define these inputs because they're going to be based on your process you have to know what your process is and you have to know what you're going to uh to evaluate in order to do this and then it gets to the decisions themselves which we have what are all of our policies so if all of our policies are met what does that look like so in this case it looks like there have been no outages in the last seven days there are none currently no open incidents uh the service criticality is uh less critical so you can use things within service now also to define whether or not to do this you can look at you know how much error budgets remaining we've got at least 10 percent of our error budget remaining and there are no uh jfrog x-ray violations that that are here this is also defined by your development team like by your change team looking at the policies making sure that we have this data if all of these things are true then we have an outcome which is our uh in this case we're going to approve the change request automatically so if all of this data so if it's raised by your pipeline all of this data is true so all these conditions have been met then it's going to auto approve it but we don't have to just auto approve it we can also reject it so we could say this is high risk and we auto reject so if it's high risk there could also be circumstances where we want a manual review so if it doesn't meet either of these the last one so it kind of goes top to bottom the last one is a manual review which goes to people so this can still go to an approver or a group or to cab it's not just about saying we're going to automate the you know automate the approval rejection it's automating your process so that you have the correct outcome based on data and that's the that's what all of this builds to which is using this data that we've been collecting that we started with visibility that we moved on to registering the change and then finally we've gotten to fully automating the outcome of the change authorization and if all these things are true then we tell the pipeline continue if all these things are not true we tell the pipeline to stop don't deploy that is that ultimate goal where we will uh where we will automate your change request but it is again a journey i should have put the slide again i'm just going to move back to it here this is a journey that goes from onboarding your teams uh connecting that and finally automating the approval process so with that we have well about three minutes i tend to go right to the line are there any other questions on the q a as we wrap up for today we've been answering them uh as they came there was a question maybe uh as people think uh we answered it but you can answer live colin that'll help others i think so the question is how does this pull info such as work items and others automatically is it sent from jenkins or does servicenow pull that information together yeah so we are pulling data from each of the tools so work items that's the generic name for like stories or epics uh or features or defects uh we generically refer to it as work item that's gonna come from your planning tool uh like rally or jira or azure devops as examples uh the we connect that because jenkins made a build that we're going to be deploying and that build we know which code went into it and we know what that code was tied to which stories so by collecting data from across all these tools and linking it all together that's how we're able to uh to specify what are the stories that that were going out um and again with that build you would also have security scans typically run so we'll be able to say okay what were the results of those security scans because it's all tied together and then we're able to walk all of that as it's attached to the change request so are there any other questions otherwise uh i just wanted to there's just one more call and i think it's related to what you were just talking about so the question is how does it know which items to pull in so when you are going through that initial app onboarding uh you're specifying which which you know backlog your team is looking at it it could be a project in jira as an example and then when the code happens as they're checking in code most development teams will reference the story id as a part of that that could commit and so we are able to link that together jenkins tells us what code commits we're in those builds so we look at all of the tools and how they tell us about their relationships even though they don't they don't store those relationships we rebuild them in their totality because we will look across like sonar cube will reference uh what build it was a part of um so we connect all the dots and so when you are deploying you're deploying you know a build or an artifact um artifact especially if you're using an artifact repository and because that artifact is linked to the change we're then able to walk all of it we have relationships set up specifically for being able to answer that question all right so we are actually one minute passed again i want to thank everybody uh there is in the chat a link to uh to uh additional webinars that are coming up we have another devops webinar coming up in uh i think a little over a month or write it a month um so we we would love for you to join that one as well and so as we wrap for today again just wanted to thank everybody for attending thank you for the the q a so we can keep this as interactive as we can make a webinar and we will certainly follow up with the questions that have been asked especially with regards to where some of the the open source plugins provided by partners resides so with that thank you again