all right why don't we go ahead and get started uh my name is Joe Auffenberg I'm a principal uh outbound product manager here at servicenow I'm supporting the devops business unit and uh working with our customers uh on on us devops uh platform uh along with me I have Eileen Leong she's part of uh the inbound product management team uh why don't you give her a quick hello there Eileen hi everyone welcome thanks for joining um yes I'm Eileen part of the inbound PM team uh based out here in the Bay Area awesome and uh I'm based in uh just south of Jacksonville Florida so uh today we're going to talk about uh our uh change velocity solution for devops so what this is all about is uh tying on devops platforms uh and specifically the pipelines into the change management workflow in service now it's also about data integration and bringing data into the platform so that we can use that data for things like Audits and for analytics and so on and then we're not going to talk about configuration data management today but that is part of the devops solution as well we'll cover that on a future webinar uh so I think first we're going to lay out the challenge uh and specifically or for developers uh it's been a little bit frustrating for a lot of the devops teams they've automated pretty much every step of their pipeline meaning uh taking their application code and moving it to production uh and even the actual final step of deploying it into production uh however for some the challenge has always been working with the change management team at servicenow working with the change managers within their organization getting that change record open uploading data that's necessary for compliance so for example the results of the bill the the results of the testing the security scan and equality scan data that's very time consuming right and in many organizations the change management process wasn't built to handle the small incremental and continuous changes that come through devops pipeline so so this uh you know if the change has to go to approval avoid like a cab the the cab meets only every you know a few weeks or so uh it wasn't very devops friendly you want to be able to make changes uh and get in the morning and have them deployed in the afternoon some of our more mature customers are are able to do that and uh we need a change management process that supports that so uh so the developer was one aspect of this but there are other personas that uh you know had to deal with this problem of course I'll change managers I mentioned obviously if you're making small incremental changes uh you're going to have a greater number of them the changes are going to happen more frequently and there's just a lot more changes to deal with so spending too much time on analyzing the changes Gathering the data for the changes back and forth with the developers uh that's something that we felt we can solve as well as the Auditors so the on on the governance side the change record is where they want to go to uh to to handle their their audit process and their governance process they they want to go to the servicenow change record and if and if they're being told well application teams have the data in GitHub or they have their data in the Jenkins console or if they have to go to jira to find uh exactly what changed who changed it why it changed and all the information they need it could be a little frustrating for the Auditors so the goal here is to get all of the data from the dev platforms into the governance system of record which is the servicenow change record of course having comprehensive change record uh it would be useful for the uh incident managers when things are changing in applications and being pushed to production without going through change management The Operators and the incident managers uh and the folks monitoring for alerts they lose that visibility right they lose their visibility as to what change so it's difficult for them to go back and see what the possible root cause might be and then of course once you um you know having uh applications that get deployed into production actually go through the process of being tested in various Dev environments and being scanned for security issues and so on and that's happening of course many different tools on the development side being able to bring that data into an analytics platform uh like we have in service now uh would be really useful as well for the the application owners and other folks on the CTO side of the organization that's responsible for for churning out these applications and enhancements really fast so what we're just to summarize uh these issues you know make it really difficult to scale devops right uh so the lack of visibility and traceability I just mentioned uh the the Auditors not having the compliance information and then of course if developers have to wait for change approval boards you know that's going to slow down delivery and and adopting devops is all about speeding up the time it takes to get new products out to Market New enhancements out to Market resolving uh bugs and defects quickly and so on so before we uh go any further I think we're going to uh jump in with a poll now so if we can uh pop the poll up for everybody yeah so Joe just mentioned you know the friction that Dev teams wanting to move fast having that speed and the compliance needed and the governance needed around those changes that are going out you know are your organization uh facing similar challenges foreign it was meant to be you know yes we have it automated already and then one of them is you know no we we need to streamline it so um yeah we plan to right but I think we could combine the first two yeah yeah okay let's go ahead and uh show the results we'll see it yeah yeah so uh between the first two folks that ought to me that's interesting to to understand why somebody would choose the first one and and others chose the second one but okay so that's about 40 I have some type of solution in place for automating this and this is what we would expect you know service now started doing this about five years ago putting the solution together because customers were coming to to us saying hey we need to solve this change management issue with devops right on pipelines uh either they're bypassing the change management process and that's uh putting us out of compliance or we're slowing down the pipeline so either you we we solved it or our customers would solve it and it seems like we're in a situation where we have a combination I know some of our customers uh worked with us to create the solution about five years ago and and I think you'll see what we put together is really comprehensive right okay so let's uh move on to the uh the next one so this is around your current if you have your change request process you know what sort of data devops data are you using right if you're connecting if you're looking at data for approval those change or change uh requests whether it's work items specific epic stories commit data test test results security results around vulnerabilities artifact versions other devops data that you're using and in this case you can select multiple answers okay I think everybody's had a chance to uh answer five more seconds all right so it looks like um work items uh epic stories and defects that's very popular right now that that that's very useful information when we think about a change record it's the what and The Who and the why the the work items give us the Y right it basically tells us why are we making this change and if we link it back to the work items in jira or in Azure devops uh that's really good information to have commits telling us what is changing uh and that's also very important uh and then of course the testing results you know where the best practices follow and then uh the security scans I'm surprised that uh more customers haven't added that to the change record but you know what it's actually kind of hard to do right the security scans are are not always directly uh tied into the pipeline sometimes that happen outside the pipelines and fetching that information can be a little bit challenging uh anything you want to add Eileen about this um yeah if you have a moment in the chat feel free to to put in you know how you're collecting this data if you're attaching it manually or if you have um some sort of integration or how that process is working for you right right I think we have one more before we move forward uh multimodal change are you using multimodal change and change management is that poll done up yeah it's showing yeah and uh we're getting a lot of responses for this one a lot more than the other ones it seems all right five more seconds to uh select your answer all right so uh many of you have never heard of multimodal changes so that's something uh I'm sure uh change management product team would like to know about and uh and a few of you have started implementing it and a few of you are planning to implement that's great yeah I think um you know supporting multimodal changes is very important for uh the devops changes as well of course you have different scenarios within a change coming from different pipelines that support different types of applications so having the ability to uh to Route those changes in different ways through the different stages of a change record uh is really what multimodal change is about and and we'll make use of that as well in the devops well okay I'll go ahead and move on to uh the rest of the slides here and uh so I'm going to just explain how the solution Works uh basically we connect to your devops tools uh we we pick up events from those tools uh so for example git commits uh new work items be created in jira uh State changes of work items in jira so if something moves from uh a a an idea to into a Sprint for example that's going to show up as an event in servicenow all the pipeline execution so the different stages of a pipeline this allows us to get a lot of visibility into what's happening in the devops platform having that visibility also helps us open a change record so basically based on the events coming in and a correlation of those events we can create a change record and understand uh some of the data points we need to actually approve that change so it's not only about creating the record uh the next the next step in that process would be to take those data points and approve it and those can be whether you know the build was successful whether it's the security scan passed all the test results have to meet a certain uh criteria let's say 80 90 of Test passing uh we also want to make sure there's operational stability in the environment so there's there's uh no incidents or outages that could impact the deployment of uh or or uh you know a new release and then of course having um uh an understanding of what's happening in the cmdb is it a critical lap is it a customer facing app how is the app regulated that could all figure into this automated change approval process once we have the data in the platform we have uh basically the performance analytics platform and servicenow we use that to provide some industry standard metrics for devops so if you're familiar with the Dora metrics we'll show you that and if you're also if you're familiar with the flow metrics these are more recent metrics that come out of the value stream management world uh that's also provided plus we have additional metrics around change uh you know change approval rates and and the success that different devops teams are happening getting their changes into production also we're tracking a lot of the data that's happening in git so you'll see developer specific information and we'll talk about that all of this is being supported by the the capabilities on the on the now platform so the common Services data model which I mentioned is used for the change process all of that figures into the solution making it very powerful so once we have this in place we can then use those uh events coming in from the tools right so we have apis to to understand those events gather up the disk the risk and then also evaluate the risk whether it's uh it meets the criteria for an automated approval and the goal is to get you know 80 to 90 percent of these changes approved in automated ways so a pipeline would just pause for a minute or so while these changes while the data points are assessed before it's moved into production and then we could actually release that pipeline we can take control of that pipeline based on this change request and then release it so that it could be deployed in production without any human intervention at all and this can take minutes whereas before it could take weeks right so obviously this is going to give time back to the developers they're not spending time creating the change records and uploading all of the test results and security scans the change managers can now handle a much larger group of changes most of the changes are being handled automatically so they can just focus on the more complex changes the Auditors uh you know and this this is also for the developers as well they're spending less time on the audit process they're not going back and forth with the developers give me access to your git repo give me access to your Jenkins console or give me the data from this Pipeline on that pipeline all of that data is in the change record so they don't have to uh uh you know go go sifting through all these different tools to find it and of course having up you know these comprehensive change records even if they're small incremental changes that's gonna that's gonna benefit uh operations and Incident Management that's always been the case with change management if you have really good change records it really benefits Incident Management by helping you determine root cause you know what exactly changed and that having these dashboards are going to give you the visibility so these are the the five personas um that are really going to benefit from this solution okay uh one more slide and then I'm going to jump right into the demo here so the um systems of record that we're talking about here on the development side we're not replacing anything here uh what we do is we respect those as the development systems of wreckage so GitHub is tracking the source control for for all the code changes uh jira is where the work items are assigned to the developers or maybe you're using Ado or maybe you are using servicenows SPM solution if you're using agile that's great you know all of those work items you know we normalize that data in the platform same thing with with the git commits if using GitHub bitbucket gitlab Azure devops get repos all of that data is is in those tools it remains in those tools and we have the ability to pull out the bits and pieces we need to create that comprehensive change record on the operation system or wreck and I should add that record becomes an extremely valuable source of feedback for the development teams it's always good if we're asking them to comply with a solution and we're giving them some Automation and we're speeding up that process it's also good to give them some feedback right and to be able to use those change records as a source for new you know new work items and new user stories and understanding how deployments behaved after they were deployed uh also provides valuable information that service now is a very good source of feedback information for the application teams okay so I'm going to switch over to a live environment here this is uh devops change workspace and uh very quickly you can see all the tools that are connected and all the changes awaiting approval uh and and this this is where you would link to the uh the insights dashboard I'm going to come back to that in a minute but first I'm going to take you through the perspective of a developer right and and just so you can experience what they would experience uh we have an application here called Globex and as a developer I'm responsible for this careers page so we have a jobs page here that touts all the benefits of working at Globex I also have a a board in jira a kanban board and jira that that uh it's where I go to see all the work items assigned to me and what's in progress and what I should be working on and what's coming in through the backlog and so on very similar to what we have in our SPM solution or what you might have in Azure devops boards uh and then what I'll do is I'll take a work item that says here the web page content is incorrect I see the web page content here I see we have some information that's not correct there I'm going to go into git and make a change to that application code very quickly I'll drill into that page that you see here and I'm going to go ahead and make an update to it and let's see uh put this in the edit mode and let's see if we swing through some of the data here um and scroll over and I'm going to remove it says here we have some good coffee uh why is this not going we're going to remove this word here because that's incorrect we just leave it as gourmet coffee I'll go ahead and commit that now when I commit it I'm going to link it to um to a work item and uh servicenow let's link it to the work item here I'm sorry the work item in jira web page content is incorrect I'll go ahead and I'll say update uh careers page go ahead and commit that now uh after I commit changes uh usually we'll run a pipeline sometimes the pipeline will run automatically let me bring this up in the in the blue ocean interface because it looks a lot nicer in Jenkins um and and this pipeline could run in any number of tools uh we're using Jenkins for the demonstration today it's one of the more common uh tools here and then we'll open up that pipeline so you can see what's happening so so we're going to retrieve the all the changes from git we're going to build the application we're going to do some validation on it including some unit testing and some uh static analysis of the code with sonar Cube at the same time also validating the config data with devops config and then as things move into um the various test environments we're going to do some more functional testing and eventually this will make its way into production now this will take a few minutes what I'll do is I'll show you a previous one the meantime this one ran all the way through the production and once we got to production before we actually deployed this change we had to get a change record open okay so I'm going to go ahead and take a look at that change record just so I so I could show you how comprehensive it actually is and I'll bring that up here so if we look at the change record we'll see this was created automatically uh by servicenow based on events coming in from the pipeline and based on the link of applications and application services to those pipelines we're able to tie that into uh the configuration item and so automatically set that data understand the assignment group understand impacted Services right so based on relationships in the cmdb we could actually understand impacted Services if you've seen the dependency map you know what I'm talking about I could see that even though I'm deploying to this Globex website front end that actually has implications by impacting other applications that might use it and based on that I could start bringing in data operational stability data uh basically are there any active incidents or recent outages uh development best practices we have all of this related List information at the bottom so I have these work items uh that's the one that might have been tied to I have commits right all the commits that were done and uh all the test results here right that were that took place in the pipeline I have software uh quality scans so if you're using Sonar Cube or maybe some other uh scanning tools we can bring in the results of the entire scan so I don't need all of this data in my decision making process but I will pull out what's important so I'll see I have some vulnerability information here there might be some security information here code smells that's an interesting term that sonar Cube uses for things that don't look right in the code you know things that don't really follow best practices so all of that data can make its way into a decision table at the same time we also have the work items and the commits so how do we now that we have this really comprehensive change record how do we approve it right so let me take a look and see if that pipeline has finished creating a change record yet this would be this one here this new one and just not quite there yet okay let me come back so the um the change policies look like this uh it's essentially we're going to take all those data points as input variables as you see here and what I can do is I can put that into a decision table with three possible outcomes or more you could have you know various possible outcomes you could have different escalations and so on and in this case I'm saying look if it's high risk I'm going to reject it if all the policies are met I'm going to approve it so that's the the automation Equity the automatically reject it or approve it rejecting it means that we're going to actually fail the pipeline and if we fail the pipeline it means that that the developers would have to fix whatever is broken and rerun the pipeline again that's a pretty extreme thing to do most of the time it would have to be something really extreme like some security violations or some really poor test results uh more often than not I want to approve the change in an automated way so we have criteria for that and most of the time this criteria exists already in your environment your your change man images have their checklist so all we're doing is taking the checklist that the change managers already do manually and applying that to uh this uh automated decision table so here you see we're looking for operational stability no incidents or outages we're looking for making sure the developers follow best practices specifically that they attached commits to their work items and that they have Branch protection turned on whatever you could come up with uh whatever you're doing today we should be able to get those data points into this decision table either it's data we already have because of the Integrations we have or we can make a back-end call with uh the uh the Flow Design and the integration Hub flow you can go and grab that data we need and bring it into this change request okay so once we have that in place we can automatically approve the change and if not if we can't meet either these first few conditions we'll escalate it for a manual approval that means that the the change will revert to its normal uh manual approval process after all this is a normal change it's not a standard change it has to be a normal change because we are in fact changing code we're changing application code and we're deploying it for the first time so you know if some of our customers might try to use standard changes for this um for this purpose but it's really not compliant to do that so as a normal change this will get escalated for a manual approval and in this case this was approved and then the other thing we could look at let me go ahead and see if we have that change record yet not quite yet the other thing we could look at is um conflicts so what we can do is we can wait for that conflict we can determine if there's a conflict using the conflict calendar now this is a capability that already exists in in change management and we're taking full advantage of it so what we're looking for are other changes that might be happening at the same time that will keep this from moving into production uh you also might have a blackout period like you see here later in the evening we we can't have any changes happening at that time or a maintenance window in this case the conflict was related to the to the maintenance window we weren't in the maintenance window so in that case with the the uh change record wouldn't move into the implementation phase and if it doesn't move into the implementation phase it doesn't signal back to uh to Jenkins to go ahead and move the pipeline forward so that's essentially how the decision process works first we look for approving it in order mated way right based on the data points that we bring in once it's approved we still have to check that um that there are no conflicts and if there are any conflicts they're going to show up here in the change record again this is another capability of change management we're able to leverage within uh within devops uh any uh maybe it's a good time to take a pause and see if there are any questions in the chat for this or in the Q a let's see if I'm able to see that I see that we have no questions so hopefully this is all very clear to everybody and that's why there are no questions okay great so I think what I'll do now is uh we'll come back to this in a minute but I'll move on to um the workspace again and we can talk about these metrics okay so what we have are various tabs here with all the different types of metrics so I mentioned the Dora metrics so on the servicenow dashboard we call them change acceleration uh I'm sorry the accelerate metrics we call them the accelerate metrics and the reason we call them in the accelerated metrics is uh Dora was a project that was started by Google and some other folks and they called it the devops research and analytics projects Dora they released a report every year called the stata devops and they needed a way to measure how devops teams were doing in various Industries so if you've ever looked at that report they'll show you uh different teams in in retail or Finance or a technology companies and see you know who who's doing the best job adopting devops and who's getting the best benefits out of it so they came up with these four metrics uh commit to deploy lead time how long does it take a commit to get deployed the production deployment frequency how frequent are you deploying to production those are two very much uh development related metrics and then of course two operation related metrics which we we've always had in in service now or mean time to restore right except we tie these back to those devops pipelines as well as change failure rates so these are the four metrics some folks call them the Dora 4. we call them the accelerate metric because that team there was a woman on that team on Nicole forsgren she wrote a book called accelerate so you can take a look at that book and you can learn all about the accelerate metrics and so these are industry standard metrics servicenow didn't invent these metrics these came out of that Dora project the flow metrics are very uh very much also an industry standard now there's a um a a new discipline called value stream management where we're focusing more on the productivity of the developers and how much work uh the system and the developers themselves can can get done in in given amounts of time so we're looking at the work item cycle time basically to to make the developers more productive throughput and distribution now this is throughput of not just development work but the the actual deployment systems including change management which is part of that and how uh how efficient that is is getting development work out to production so this is very useful set of metrics uh and they're called the flow metrics all of these metrics whether it's the door metrics or the flow metrics can be delineated by either applications right business apps or services so this is the that connectivity to the cmdb again we can use cmdb things like business services and CIS or they could we could look at it by like development team or git repository right and this is uh very useful in this regard now the other thing we also have is data around operational stability there are a lot of devops dashboards out there but no no one else combines the development data with the operational data the way servicenow does we just have more operational data than anybody in the form of incidents and outages and service availability plus we bring you back into the development teams and you can see how well different developers are doing the top committees the top converters uh and so on and so forth uh the past percentage of the pipelines uh things like commits that don't have work items so you know ensuring development teams are following best practices is critical here uh and and so this all brings you uh into that data and gives you the ability to analyze it across the different teams uh another set of metrics we have in a quality metrics so this is coming from the uh the scanning tools and the testing tools so looking for vulnerabilities and code coverage and then of course change acceleration so this helps you understand uh how the the solution you put in place with change velocity uh what what impact that's having on the various teams so we're looking at automated versus manual changes uh we're looking at the uh the decisions of of of how to accept the changes how how well they're being Auto approved or not uh whether the all the policies are being met or some of them are being escalated for manual approval and then of course very important developer hours save right and the savings associated with implementing change acceleration we know development time is probably the one of the most scrutinized resources within any organization is is understanding uh how the development teams are using that time so we can show how much time we're saving those developers it becomes really uh compelling and it helps actually with the adoption of our solution here uh so that's it for devops change uh any questions at this point do we get any questions yet no yeah see one question in the chat so from this dashboard can we uh be able to see relations to a business service so so yes you can see there's a filter there for service it'll just pull any of the service application service business service there um there is that connection that there are mapping where our data connects to the cmdb so you'll be able to filter by services or by business app or even buy products in the product model table as well so we have a lot of good connections there in the cmdb yeah and one thing I should add is is when you set these settings they persist so if you log out and log back in you'll get the same dashboard settings that you had the last time you said although persist based on your route you use a profile yeah so I think um that's all I have now now uh we were going to um show you one more thing Eileen which is going to show you how to actually get started with uh devops change um there very quickly let me just bring you back into the slides here um there is a a couple oh there is one more poll question here it looks like yeah let's uh let's start with that okay so were you aware of this solution prior to this webinar okay so we have some results here to share with you uh it looks like um most of you had heard of it more than a half and uh a few of you have installed it which is very good thank you for that and some of you um this is your first time hearing about it okay and then the second question is what is your usage of devops change velocity today uh and about a quarter of you are evaluating it in subprime well that's good great but and then another 17 are looking to get started with it in the next three months and for some of you this is not a priority at all okay I think we got another question here right so this question is around you know hearing what you heard around um the devops change velocity you know if you're thinking about automating changes uh getting it automatically approved some decision tables you know what do you see is barriers or challenges to you just getting started with this foreign we'll just give it a few more seconds here all right so I've seen the majority of people uh just would like more information understanding of the product um along with uh buy-in from the development counterparts uh to modify the pipelines and other assets when the third running is the change management process updates okay yep makes sense um with that I can go ahead and show you a quick uh a quick demo of how easy it is to get started right so initially uh to connect tools or or bring data in you know you're not going to need a lot of you're not going to you can do this passively you don't need you know specific buy any you can just get started pretty quickly um Joe did you have anything or do you want me to no no we did get our change record here so I was going to just go ahead and approve that it looks like we've also got escalated for manual approval but why don't you go ahead and uh um show how to connect the tools at least just give a basic uh understanding so so folks could go ahead and you know play with that at home yep uh pretty quickly here oh I did get pinged with one question you know how do you get access to devops uh change velocity and you know this is part of your itsm pro package or I guess some Enterprise package CSM Pro Enterprise as well so if you have itsm Pro you know feel free um this is bundled uh with that license so you can install it test it out try it out you know minimally you can connect tools get data into the system and at least start with some of those nice insights dashboards or visibility into the data coming in right um as as the first step and Joe we'll we'll talk a little bit of the adoption Journey here um but really quickly I just want to show you um it's a teaser for a future Workshop that will go more in depth on how to really onboard and get started but you know you install devops uh change and you would get access to the workspace here and this will really help guide you through setting up there's a few things on the left hand side the servicenow admin would have to do which is essentially setting up system accounts getting integration user in place and we use that integration user to create web hooks for some of the tools but really once that's set up really a simple step there it's all about just connecting the tools to get the data in right so we have a lot of different capabilities planning tools like jira coding tools for the repositories and commits GitHub bitbucket orchestration tools for the pipelines and so forth I'll just give you a quick example of getting uh Azure devops connected here so I can connect an organizational level devops cool here so ideally you'd connect you know a planning tool for work items uh uh holding tool for commits and an orchestration tool for your pipelines and that gives you a good Rich amount of data that can come into our system right you can see the pipelines that will automatically bring in uh the unit testing as well um that are just run through the pipeline and then it will also bring in the commits that are being deployed and those commits will be attached to the work items and we give you that traceability of the devops data that that Joe was able to uh show on his changes there so I I entered my Azure devops credentials there it gives me a quick look at you know are these credentials what are the permissions available for them looks like I have everything that's needed for that and then from there it's going to uh connect to Azure devops and starts automatically fetching all the different uh plans repositors or pipelines since Azure devops is a multi-capability tool we have the ability to restrict access to the tool to if as well for different groups of users about go ahead and skip that for now and make this available to any of the devops admins we have here and you can see that it's automatically pulled in six of the projects within my Ado organization I'll go ahead and put in the integration user password that was initially set up by the servicenow Admin and I'll just choose one project here as an example it lets me know obviously if you select a lot of projects it might take a little bit of time to pull in all the data right it's it's going to look at that project configure the web hook automatically and discover all the plans repositories pipelines for this demo project here I selected and really that was it um from here I can go to the tool record itself and I can verify yep it's connected uh the permissions were there those six projects and that one that I configured here with the web hook it pulled in the plans repos and pipelines um so you know you'd come in connect the various tools that you're looking for and then really it's all about creating that application so I can go in here and create a new application I don't have any yet in the system give it the name or webinar my application here and really just like that it's uh I've created my my application here you know you've got a connection to business app but really then you just need to associate a plans repos and pipeline this application provides a nice grouping amongst those uh artifacts so that we can appropriately link the data right so now that I can come in here and Associate a specific plan and it's going to pull up you know anything that was discovered from the tools there so I can go ahead and select this uh plan and even import data to get started right away with my insights dashboard and really you just associate your plans uh repos and pipelines as the minimal first step to get started here so just like that you know you can connect a few tools get your application created um and then you know your your insights dashboards and you've got data coming in quick easy first steps for you to minimally see some value uh pretty quickly here you know within within minutes or even hours yeah that's great I mean let me um put that into context of the oh adoption Journey here sure and so what Eileen just showed you is how to connect the tools and apps that's the first step and what that's going to give you uh all the events coming in from the various tools so you'll get the work items from from ADL if you connect Ado you'll get all three of those domains of data the work items from the projects the git commits from the git repo and the pipeline executions from the pipelines as well as any of the test results that come through those pipelines that will give you enough data to start feeding those dashboards and to create those comprehensive dashboards that give everybody insight into what's happening in the devops tools uh once the data is in the platform the next step on your journey could be just creating the changes manually but then linking that data to the change record so that gives you the ability to have all of the results of your testing and the artifacts that get created and the work items that get uh attached all of that data can then be manually attached to change records so the developers will no longer have to manually upload the the the test results for example or upload or the details about the commits what change they won't have to do that manually but the change record will be created manually won't be created by the pipeline the next step on the adoption journey is what we call a change registration these are automated change records that get created by the pipeline without actually taking control of the pipeline so the pipelines will continue as usual it's a very good option because it's still happening in a passive way you're not asking your developers to change their pipelines or to or to give control over their servicenow but you're still meeting the compliance requirements of the Auditors right you're creating these comprehensive change records with all the commits and work items and test results and security scans all of that will still be attached to the change record but the pipelines will continue on as they would have without that and then of course change automation is what we just showed you it's the ability to take control of that pipeline use the data points that that we just discussed and use that to determine can we we approve this change or reject this change in an automated way so those are the four uh steps to adopting this and you can do this team by team so connecting the tools and the apps that could be done in in a grand way in a big scale you can connect to lots of tools lots of apps get the data in it's very easy to do that within a few weeks you'll have some really nice dashboards to uh to show your managers but the adoption of change automation is something you normally do team by team not every team is ready or mature enough to take advantage of this but the teams that are on especially the teams that have a lot of manual change records they have to open or spending a lot of time interacting with the Auditors that's the those are good teams to Target with this uh solution okay any more questions I think we did have one more full result to share and that was um the uh about the challenges getting started it looks like uh that was never mocked as done but I'll go ahead and share that and what we see here is um just having uh buying from development and more information and understanding of devops change velocity and we hope we hope that this session today gave you some of that and we'll help you go back to your development teams and explain the value that they're going to get from it right not just what the servicenow platform people and the and the directors get going but but also what the application teams are going to get the benefit of you know hopefully not having to spend so much time in service now um and then the uh just uh just the last thing was the um you know just to summarize all the benefits uh the the challenges just to understand heavy heavy problem we solve here you know transparency compliance speeding up the process that was taking too long and just reducing the amount of manual activity uh being able to do this in a big way across many teams uh extremely useful and of course what you get out of it the benefits are all pretty laid out uh here you know automation is always good but but being able to provide more time back to the developers so that they can fix those bugs and fix those defects and uh spend less time on the administrative side that's obviously the big benefit having um data we had we have the uh the the change records that the Auditors like to have all in the same change management system that they use for you know infrastructure changes and and network changes and and changes to underlying systems and to have the devops changes all in that same place is extremely useful and uh you know held with compliance and being able to do this in a passive way right the developers stay in their tools um that's most important we're not asking them to change the way they're doing things but to be uh but to do this in a passive way collect the data we need and make the decisions we need to make okay so um okay so this is the pipeline I started at the beginning of the demo and uh we can see that eventually it did complete it was approved uh we were able to publish the updates to the application and I think if I was to go back to my uh blowback's web page and refresh the page we should see that the uh coffee the the coffee gets updated there all right so were there any um final questions uh coming from coming from the group here I see one in the chat okay uh okay no I think we're good we can um move on we do have a last poll here about a workshop and we are uh also planning a workshop in June really to gauge interest in this it will be a a Hands-On Workshop you'll have access to your own instance you'd be able to follow along really see how you can you know connect tools I show you a brief snippet in My Demo I gave you but this would be a a full-on end-to-end workshop you know getting pipelines up and running looking at the change approvals um so really excited and hoping that you guys would be able to join us there for a deep dive foreign awesome so I guess that's it I guess we can wrap up thanks everybody for joining and uh let's just uh see how many of you are going to be attending that Workshop looks like we got 100 of responders said they're going to attend the workshop but I think I think our mission is accomplished here I mean we we do have a few more questions that popped up um I'll just answer I'm really briefly here uh you know what tools do we have Integrations for I gave you a a quick look when I went into the the workshop and uh showed some of the the models of the different uh logos that we have but essentially planning tools like jira um rally you know Azure devops uh coding tools GitHub bitbucket orchestration tools Jenkins you know git lab GitHub pipelines um Azure devops you know we pull in those tests tool test results automatically for a lot of them but we do have artifacts security tools um as well that can be linked up and uh the second question here how long does it take uh to get value uh from from devops um I think we showed you you know the in the adoption Journey right that first step of connecting tools uh getting data into the system um can be pretty quick right you can get get some value uh within within a few hours just getting set up getting data into the system uh the long poll that we generally see of customers is uh the change approval policies themselves you know getting agreement buy-in amongst the different stakeholders that can be a little bit longer um so you know we understand that that might take some time but you know looking at the job adoption Journey there's different steps you can take to get there would be a good time to mention that most of you probably already own this it's part of an itsm Pro license so uh there wouldn't be any additional cost of your license behind TSM Pro yeah and uh this call to action here really uh you know since you have it Sim Pro um really urging guys just try it out get us started it's meant to be self-served you can install it uh quickly onboard a few of those tools in that first step and get data in to create one app make those associations and start there and then in the the workshop we can go even further than that to continue that story goodness all right last uh call for any questions here before uh we wrap up yeah just wanted to say uh thank you everybody all right thank you everyone we'll see you uh in June