hey everyone thank you for joining our fourth session of the modern change management launch and learn today we're going to be covering a change automation with devops we have a new speaker here today Joe offenberg I'll interrupt him in a second to give us some some context and walk over a pretty cool demo let's jump in okay um as always we have our Safe Harbor so um there may be some forward looking statements in this presentation they're based on our best understanding at this point in time so so uh just don't take anything as set in stone as it could change okay so now let's get into um our topic for today I want to start by bringing us back to uh the adoption journey and kind of where where we've been and where we're wher we're going today so we we started this series off um you know talking about how we replace our Legacy workflows with flow how to reduce our technical debt and how we can start um you know defining change models uh we then moved into governance and really how to make make sure governance is right for the context that we're using it so um how to adopt approve of policies to you know automate some of these governance decisions um and then we continue down that automation path really looking at the data and how we can use data to drive this Automation and uh the various ways we can assess risk um ultimately we were looking to take the subjectivity out of the change process you know where it's appropriate um and really driving traceability and the vity in the change process so today we're going to kind of really go through this bottom row and give one example of um you know of this maturity Journey using devops so how you how you can connect with your CSD tools um how to automatically create changes for pipeline pipeline executions for application code changes and then ultimately how to get to you know full change automation so with all this um you know as we mature the change process we're looking to improve velocity volume stability and uh compliance um we started down this process oh I would say about five or six years ago and uh customers were coming to service now and saying hey we we have a problem with change management right we have uh teams are development teams are becoming more autonomous and the development process has is moving Clos closer to the business and away from it uh and what started happening is we uh we started losing some control and visibility into what changes were being made in production right so they adopted methodologies like devops where uh under uh continuous delivery for example you're making small and incremental changes continuously to production and we needed to be able to capture those changes in an automated way so this is a a perfect example of why uh change models became important uh as a way of uh simplifying the change process for a lot of these development teams and enable them to uh move fast move their code into production quickly but still allow us to put compliance around it put controls around it make sure that they follow all the necessary uh best practices they run their security scans all the testing results look good and so on so this had a lot of uh uh benefits for them as well as for the it organization they spent a lot less time on administrative processes like opening a change request and providing data for Audits and we were able to ensure compliance in a much more rapid and and efficient way so what this means is um there are a lot of benefits for a lot of different personas here so developers themselves obviously if they're not spending time on opening the change records they get that time back they get to spend that time on what they're supposed to be doing which is enhancing the application and fixing bugs and so on uh once you attach change management to devops pipelines right you're going to get a lot more changes and in order to handle a large amount of changes we have to be able to automate approval so we uh provide that capability as well and you'll see that in the demonstration again another capability of our modern change uh solution our modern change narrative here uh and then of course uh the Auditors are very happy because the change records themselves are more comprehensive there's a lot more data and the data is more accurate often in the past developers would simply check a box that they did the security scan or check a box saying that they ran certain activities uh more of an attestation right but in this in this case we're getting data directly from the devops tools and we're able to uh automatically approve those changes based on those data points we get and the audit the Auditors are happy with those those change records you know a lot more of them but they're very comprehensive and they capture now this benefits the operations folks as well change management has always been a great benefit to Incident Management going back to the early days of iil uh you you know you want to know what changed when an incident came in however uh the changes become more and more complex and uh maybe uh more uh um actual things are changing in a change record uh in devops we we're making smaller changes right and more incremental changes so imagine these changes on a timeline right before an incident happens or an alert comes in we can see very specifically which change happened right before the alert and in that change it might only be a couple of lines of code in an application that changed we can tell you which file was changed in the in the git repository for example and uh how that might have impacted the application and so on so operations benefits and then of course of course all the data we're collecting to make all of this work you know we can provide analytics right we can provide uh some dashboards uh some industry standard metrics some folks might know the Dora metrics right these are metrics that came out of research at Google actually and they started a project called devops research and analytics Dora and these are the Dora metrics and we provide those on our dashboard another set of Industry standard metrics are the flow metrics so these are really valuable for all the stakeholders not only in the it organiz ation but also on the CTO side of the organization the application owners the product owners and so on they want to see how well the adoption of devops is going and what benefits they're getting from this adoption right and that's and that becomes clear so just to sum up the solution we connect to devops tools to to bring that data into the platform uh modern change could then take advantage of that data to uh uh create the change record uh with all the necessary data look at a list of criteria and then decide hey can we Auto approve that right and then of course having those metrics there uh to be able to measure performance including the D metrics okay uh so so where does this fit in if you've watched our previous uh series on Modern change so we are right um smack in the middle of the uh you know Federated change model and I would say we are probably one of the most mature examples uh when we look at the model for modern change uh the devops change uh devops change acceleration change velocity I should say is is basically the the most mature and most valuable way to um Implement uh change models and change of Auto approval processes and uh take advantage of things like change success scores and so on all of that can fit into uh and you see all the check box we get here under the um the Federated change models for devops okay so uh the key components of this again model States so if you're familiar with the change models this allows us to simplify the change process and make it fit to purpose so make it a very specific devops change model with uh certain phases and certain transitions uh and a state-based flow between those changes with conditions required to move from let's say a scheduled state to an Implement state right what are some of the transitions for example if it's in Conflict you know for one reason or another we don't want to move into the Implement State until that conflict is resolved I'll show you how that works in the demonstration uh the Integrations we provide the necessary data to feed into uh these approval policies come from the devops tools right we need to know all the Test passing all the security scans are they successful uh we need to know all the information about who made the change what was the change for we get that from Tool like git and jira for example and then that's how we uh we we provide this outcome and then so this is a uh probably the best example you'll find of why the change models can uh you know really help to improve the change the change management process you know other examples might include provisioning in the cloud so you know you go to a service catalog you request something to maybe uh reconfigure a running instance in the cloud that that's also a very good example of modern change it's automated all the data is available from all the tools and we could uh apply policies to those changes right and and this is just you know several ways where the modern change process is is uh assisting okay so at this point I'm going to switch over to uh the demo environment and I guess first I just want to see if there are any questions I see Margarita still has a hand up but I think she might be stuck with a hand up is there anybody else uh a question there no okay any questions you could just throw it in the chat and uh we can get to it there Joe there is a question from Coleman you might want to take uh light and uh from DJ do you want to come off mute and ask not really but I can I can repeat it so what you're demoing here does this assume that you know the teams entering devops or capturing testing approvals Comm all those things that they normally would do does this assume all that's being done and they're just kind of providing that into the devops module well for the most part yes so what this is is you know as part of their uh pipelines they are um they're building their application they're testing their application and then they're uh putting their application into production those could be you know different pipelines right one one pipeline builds and another pipeline does the testing and then you have deployment pipeline like a week later yeah the only reason I asked is because I've been attending all of these and it's all good stuff but all of it assumes that they're doing all these kind of Agile Release management activities before they get to change so I just want to make sure that I've got that squarely in my head because in the real world a lot of Team a lot of companies that doesn't work that way so that's why I'm I'm I want to understand the approach that was used to design this so that we're solving the problem for for the customers that that do work that way and they've come to the you know itsm folks and say hey change management is is the bottleneck it's slowing down the process right if you have teams that aren't that agile if they're not using automated pipelines then you know maybe a manual change uh at least for them is is is acceptable it works because it's not slowing them down does that make sense yeah no 100% I just want to make sure I understood the architectural design approach that that was being taken for entry here so thank you I appreciate it Y no thank you DJ appreciate the question uh okay so I'm going to start in our devop change workspace here and what I'm going to do is I'm going to take you through some of the tools that I have connected uh because I'm going to run through an example basically the day in the life of a developer uh developers the goal here is to keep developers in their own tools right we don't want developers to have to log into service now to create the change record or to check the status of the change record all that information should be provided to them in their tools and if if everything's working the way it's supposed to they won't ever have to log into service now for this process it's it's going to collect the data we need it's going to decide whether it's okay to to move to production and it's done in a very passive way without engaging a lot of effort on their part and that's the goal right because we know that that you know this process is only going to get faster and it's because these you know companies are competing now with software applications it's all revenue generating applications uh that you know whether you're uh manufacturing tractors like Caterpillar or you're a financial company and you're trying to create new capabilities in your phone app and so on you have to be able to do better than your competition and that's why this is so important right so if we look at let's say the the world of a developer they might have a uh a planning tool like jira right and you know I know a lot of you are thinking hey service now has a very nice planning tool or SPM solution uh but I'm showing it with jir because you know they do own a big chunk of the market and most of our customers use jir so uh we use um work items in jir on the caman board this is interesting information because it tells us you know why are they making the changes right so you see the work items in various stages but we support jir of course we support our own SPM solution we also support Ado boards and they have a similar work item caman board for example uh and and uh you know GitHub issues is another one where Developers track all the work they're doing and this is important information we bring this into the platform uh then a developer will take something that they're working on let's say a bug fix the report's not working here they'll go into GitHub and make a change in the application code uh in this case I'll go ahead and uh I'll update uh one of these files here and I'll commit that change and as a best practice we expect the developers to go ahead and Link that change back to a uh a work item now if they don't do it we can we can make sure they do right that's one of the um the data points we're going to check are they following best practices are they linking their commits to their work items uh that will be one of the line items in our policies okay and then of course uh we have a pipeline tool in this case I'm looking at uh Jenkins I'll go ahead uh and run another job here and that'll kick off a new job and what you'll see is in this Pipeline and this is typically the way these devops tools work uh they'll build the application they'll build an autofact they'll test the autofact and then they'll do some more testing in a uat environment for example and then at some point they'll deploy it to production now this usually doesn't always happen in one pipeline usually there are several pipelines but either way uh we support basically linking the data to the artifacts that are built and then getting the data from uh when they test the autofacts right so the autofact becomes the key that that ties all the data together and then when we deploy that artifact or the a or several artifacts we have that information to apply to a change record now if everything goes smooth and let me show you some of the previous ones like this one I could see it ran in four minutes right that tells me right away I know that was done with an automatic approval so just before it went to production it opened a change record and you can see we say here's the change request number and within you know two minutes or so we have Auto approved it based on the policies so we've gathered up the data and we said you've met all the conditions and this particular pipeline ran all the way through the production in a matter of minutes okay often that's not the case uh but the goal is to do this probably 75 80% of the time so now let's switch over to service now and let me show you what's happening when these pipelines are running okay I'm going to drill into that particular pipeline here and this is the pipeline from the service now perspective what you'll see is we discover all of the pipelines and the executions we discover all the git repositories so you connect the tools and we can discover all these resources once we've discovered it then there's uh some onboarding steps for example when you have a certain step where you want to open a change record you have to specify some detail like the change model we want to make sure that this particular uh step is going to use a change model to create the change record for a devops change you might want to use templates uh you might want to have different application groups assigned and so on and then you could you could add other fields as well by modifying the pipeline itself and adding those to the uh directive in the pipeline okay so then um from here uh let me go back I can show you uh from this pipeline uh the visualization we provide right so on the service now side we've never had visibility into these pipelines so here you can see the building of a uh uh of an artifacts uh the testing of artifacts uh here we have the commit messages and so on uh we have the software quality scan so this is using a tool called sonar Cube so this is all really rich and uh interesting data and and here's even the security scan right in this case it's veric code all of this data makes its way into that change record okay so what that means is uh we can use the data in the change record uh well very simply to understand who's making the change what change are they making what are what files are they touching uh very important uh the security summaries are attached right so I could drill into for example the veric code scan I could see okay there's some uh medium level vulnerabilities so if I was manually approving this change I would have all the data I needed right I can I don't have to go back and tell the developers to attach files to the change record right all of that data is here um the the uh you know the the versions and and so on all of that is attached uh in the case of uh uh the one I just made again all of that gets attached to the change we have a new change record here let me go back to our open up another application this is the Globex one here look at this Pipeline and view that pipeline so this is the one that I just kicked off a few minutes ago um and I can see this one looks like it was rejected I'm going to find this specific change okay this is not the right one let me go back do that pipeline right in pipelines I might have clicked on the wrong one I guess this is the one I want okay this is not the right pipeline let me just show you the change record um and this change record is uh basically um created automatically right and what you can see is all the data that we collect uh there's the uh commit that I made a few minutes ago there's the work item so this is telling us why we're making the change this is telling us what's being changed who's making the change and so on uh the test results are all listed here uh for this and the software quality scan all of that data is in the change and then what we could do is we can apply uh change policy so I'm going to switch over to our service operations workspace here and I can show you what that looks like from that angle um yeah so if for example here's a here the uh let me bring up this change again so here's a here's the view from the service operations workspace all the same details are here uh I could also see that this particular change is in a uh a conflict and from here we can see okay what's happening what you know why is it in a conflict right so even if we automatically approve this change there are other things to be considered uh is there a Blackout Window is there a maintenance window if there's a maintenance window we'll actually wait for that maintenance window to occur and again as part of the uh the change model we can decide uh based on the data we have is that enough to transition from the schedule phase to the Implement phase and in this case we decided no we won't go to the Implement phase until we get to that maintenance window again this is all automated you don't have to log back in and and check we also see there are other changes happening at the same time impacting the same CIS uh and so on this makes its way into uh the decision you know whether to Auto approve or not uh the other thing we could do is um look at risk right so you might have uh uh some risk information here um we're going to have uh let's see yeah so so basically what we're doing is we're taking these data points and we are assessing them from a a development point of view did developers follow best practices uh from an operation point of view uh are there any active incidents or outages right we know that based on the configuration item we could look in the cmdb and get that data and then of course security we want to make sure all the security scans look good and those results can now be figured into a uh change approval process so you see here we have a change policy right again uh all all part of the uh you know the modern change solution where we can now take all of these data points you see they're all input variables now as they're represented and then decide on you know can we approve this change in an automated way if it's high risk we can reject the change right that's the answer let's reject the change if all the policies are met uh then we could we could approve those changes and then so you have all of these um data points where you can put thresholds on if if if it falls within um you know if there are no outages for example or no open incidents or no security vulnerabilities uh the software quality results we have all of that we have other details related to the software quality results you can drill into and so on all that data becomes available that you can use in a decision table to automatically approve that change and if all the policies are met then that change will go to production so for example in uh in this pipeline here um here we open the change let me go back to the previous one here uh this change was automatically uh approved and it was approved by a you well this one was actually manually approved right because we see the approver the name is here and we even see the comments they put now this is inside the the tool so when something doesn't reach the point of an auto approval it got escalated for a manual approval and then from the developer standpoint they can see exactly what's happening they can see that these uh steps are taking place in the service now platform but they don't have to log into service now to see it it's all showing up in the console of their tool same thing with Azure Dev Ops right when the pipeline's Run we update the pipeline with with lots of information so for example we can see uh during the um deployment phase of a pipeline the the change record was open and then at every state change uh of the change we provide data into the console in Azure devops pipeline so regardless of what tool you're using it could be GitHub it could be Ado it could be Jenkins it could be jira gitlab we support all the major devops tools we can capture this information and it all works the same way and then in the platform we normalize that data right we bring the data in from all the various tools we know in many large organizations there are multiple teams using different tools however being able to normalize that data in the platform is very valuable right so if we look at the uh let's go back to our devops change workspace here and we can see for example our insights dashboard regardless of what tools you're using or if teams are using different tools uh we can see uh the data across all the different tools and it's all normalized so for example I mentioned the door metrics uh we have the um average lead time this is basically how long does it take commits to go from the git repo into uh production right so developers make some change and then it takes roughly n days for those changes to make it into production uh this is across all the apps I say okay let's look at it for a specific uh app so let's look at the hotel reservation service right I could see okay for them uh it's taking a little bit longer they're not deploying as frequently and it takes about 20 days uh and also I see their mttr is very high you know to resolve incidents is taking uh you know almost four or five days there so we want to be able to bring those numbers down we could identify which teams uh could benefit most from this type of automation right using these metrics okay the other thing we have here are the flow metrics now flow metrics is a way of measuring developer productivity measuring developer productivity not by how many lines of code they write but how many work items uh like enhancement requests uh bug fixes and so on they can uh move through the process into production so this actually goes a step further back before the G commit like the dorom metric we go back to when the work item is created when the idea is created that this needs to be fixed or this needs to be enhanced we start the clock there we get the time stamp there and that's the average flow time that's how long it takes these work items to move into production and so on so you can see how this is uh beneficial when trying to understand you know how is devops impacting our teams and impacting our ability to comp compete with our competitors with our applications we also measure accelerate the accelerate metrics uh these are those door metrics I mentioned the um sorry the change acceleration metrics is really about what impact we're having on the change approval process the time to close changes right automated versus manual changes so you can see most of our changes are automated throughout the week here uh we see changes waiting approval and so on so this is a way of showing the teams that haven't yet adopted this solution the benefits they can get from this by by automating their changes and moving faster but still uh ensuring compliance okay so that's uh devops change velocity solution uh I'm going to take a pause here we covered a lot and um see if there are any questions I see uh Joe um there question asked the um on the chat which was um approaches for on boarding at scale so you know when you got thousands of pipelines because you you stepped through one pipeline there that was kind of very pointy clicky and a really good way of doing it for a small set of pipelines when you got 6,000 uh what's our experience of approaching that yeah that's a good question so uh there is a an adoption Journey here right and um if if you just want to connect the tools and get the data you can do that at scale very quickly because that involves just connecting to the tools discovering the resources and that will get the data into the platform that will get data feeding those insights dashboard from there you can move on to change traceability uh this again this is just the ability to create change records with the devops data you brought into the platform this could be done at scale as long as you have access to the tools and could get the data into the platform uh even the uh the creation of changes uh in an automated way this could for the most part be done at scale very quickly you can create templates that the developers can use in their pipelines to create the changes uh when it starts getting difficult and when the the scalability of this starts to uh become difficult is when you is the change approval policies okay that requires collaboration and it often requires team by te collaboration I mean you can set change approval policies that are Global across the whole organization and then layer additional policies on top of that specific to a region or specific to a business unit and then eventually some teams are going to need some tweaks to that so the scalability starts to become difficult at the at the change approval part because it involves collaborating between people whereas all this is just technology connecting to technology and getting the data in the other thing we provide are apis right so to help with onboarding for example there are apis that can be used to generate the app records that connect all the resources for an app and so on so that will help speed things up quite a bit uh but yeah as far as um just connecting the tools getting the data in the platform that's something you can do very quickly and and and you know within a few weeks you can start seeing the results in the dashboard okay I hope that answers the questions yeah thanks Joe there's a there's a hand up from Marcus I saw earlier oh there's a few hands up up so are we doing hands up now yeah we can do some now Marcus y thanks Dan hi Joe I put my hand up when you were going through the uh the risk assessment there and I saw calculating a low risk high risk whatever which is pretty much entirely based on those policies you set so did it meet this policy and this policy and this policy and therefore it calculates high low risk yeah yeah comparing that to an Old-Fashioned change where you will have some form of manual risk assessment I think you touched on it yourself actually that you you'll manually answer some risk questions um would you recommend that that's Switched Off for devox otherwise you've got to try and find a way to get those questions answered from the pipeline yeah so that's basically what you're implementing right if you already have change managers that are manually assessing Risk by going through a checklist that's that's more than half the battle in my opinion because you know when I started doing this I thought that most of our customers had that already because they were approving changes manually they had a checklist of some kind what I didn't realize is that a lot of change managers actually use gut instinct and it's hard to put that into a decision table but if you already have that detail decided you know working backwards from what it takes to approve it and putting that into policies uh is pretty simple and pretty straightforward um there's also other ways to do it right we have uh uh success scores for change approval teams that can be utilized you can use risk calculations and just have one line item in your approval policy but have a lot of different data feeding into the risk calculations so these are all capabilities of of of modern change that you can take advantage of I I showed that example because that's um using a decision table based on a list of approval uh criteria is the way most of our customers are doing it manually today so adopting an automated way on from that is is the quickest path forward but you can get more sophisticated does that does that help answer your question um not really because um we haven't found it easy which is why I'm asking the question so so it's the change owner answers these questions there'll be a question about testing answer a question about testing which teases out the quality of your testing and how complex is the implementation and etc etc so with an old fashioned change they're just manually answering those questions how do you get the pipeline how do you get the pipeline to answer those questions or is it just best to switch them off when it comes to devops yeah I think the the the big thing about devops is the changes are much smaller and more incremental right and the also the other thing about devops is if something breaks you should be able to uh fix it quickly because that's the nature of devops so when customers ask about like a roll back policy most of the time in a Dev op scenario you you roll forward you don't roll back you say oh we broke something with this new update let's fix it quick boom let's get it out and again as long as it goes through all of the policy checks that we have you know the security scan the functional testing the performance testing and so on that's then it makes it through the pipeline fairly quickly um if there are other impact assessments let's say for example you have a um a change uh and and you know I can bring up one of those changes again that I had before um and you want to understand uh for example what's the impact on This Global web service or it's a configuration item what other services are impacted by that configuration it the data is there right so you can see the relationships and then you can use that data as far as understanding are there any active incidents and recent outages so when when somebody's manually trying to impact understand the the assess you know assess risk what steps are they taking to do that manually and can we do that in an automated way so I I would add to that Markus as well just to say that um when you have a risk assessment for a normal change you're you're to cover a lot of bases with that right you could be doing a patching change you could be doing an infr change um you could be doing uh an infr change across the whole load of systems and you need to gather some information and that isn't always obvious from even if you've got a very good CNB it's something that maybe you need do need to ask a question about um with the devop change you've got a pipeline and that thing can only deploy to a certain place um and also with that pipeline run it only deploys in a certain way steps will be followed through automation that ensures it's going to run in a certain way as well and that steps will be followed as that pipeline executes the tests will happen um and security scans will happen and they'll be recorded so you've got a lot of structured data and even from within the kind of more traditional change route if you haven't got a pipeline attached you know we we we kind of favor use of structured data like instead of asking whether it affects critical service we have a risk condition to say is a critical service impacted by this and you can still use risk conditions for devot change the point is with devot change it kind of makes a lot the it makes the risk assessment questionnaire obsolete both in terms of the nature of Joe was saying but in terms of the small incremental nature of the changes partly because normally you've got a larger Release Train on top of it which is taking care of some of the larger organ organizational kind of business context questions um and also because as part of um of of part of what you're doing with devops uh you have a lot more structured data and you can answer the questions directly so that's normally the case but if you have specific questions Markus you you know my number we can you can have a call and we can we can talk through the specific questions I think that last little comment you said there may have answered my question in terms of the traditional risk assessment questionnaire becomes obsolete so stop trying to make that work yeah you can't I mean you can't you can't hold to Dev change because someone's got to answer a questionnaire um and ultimately even if you did want to do it the devops teams would just start doing the changes without raising changes most likely in organizations I talk to right you just end up you're better off seeing the changes and uh and monitoring success of fail uh from a controls perspective we'll say we are still performing a risk assessment but we are not doing it via this method we're going to switch that off we are doing it via this more automated Devy method exactly exactly yeah and the change of approval board now has a new role right they're not they're not looking at each individual change they're looking to make sure policies are enforced and which policies get enforced in which scenarios so it's this basically the same outcome you know control over what gets deploy in production but it's a more automated way of doing it yeah thank you do we have other hands up or do we need to move on Greg your chairing this so you can minutes yeah yeah we have one more hand up if you want to do that Robert um you want to come off mute you guys hear me okay yep all right very good just a quick question we did implement the devop CV uh module here at our organization but one of the one of the things we're discussing is once it creates the change request and of course the change requests uh are populated we're using a standard change request which typically has two change tasks as you know you have an implementation task you have a validation task have you seen uh implemented where the pipeline can create additional SE tasks as needed based on the pipeline so I might need three teams from this pipeline to do validation as opposed to another pipeline that may only need one validation task we're struggling with how that might be accomplished if the pipeline should create whatever additional C tasks are required for that change request yeah so so two parts of your question so you're using standard changes and I think um actually normal changes oh normal changes okay then then that's fine yeah because standard Chang at least for now wouldn't be appropriate in that scenario okay but a normal change you want to add additional tasks to the change yeah so whenever the change kicks off uh whenever the change is created there is an integration Hub flow that runs in the background that basically is going about the business of getting data and adding it to the change and deciding what happens after it's approved and step by step I can show you what that looks like but the idea is that you can add additional steps to that and we provide um we provide some out of the box uh let me show you back in notching but you can modify that to add additional tasks if you wanted to based on criteria right so um the one we provide out of the box is a very simple one and we encourage our customers to make it more you know appropriate for their process so if you look at the change approval guide you'll see these flows here um even the most advanced one is actually pretty simple so most customers will start with that make a copy of it you know make a clone of it and then use that instead of uh the one we provide because it's really just a starting point like a demo almost right that you can use and then here is where you can say okay from that original change creation let's gather up some data but let's also add some more tasks uh to the process and you pick the appropriate placees to do it but uh if you're familiar with the integration Hub and the flow designer it's pretty straightforward too and yeah from from a change point of view as well to add to what Joe was saying and everything Joe's shown you is completely correct the flow that's triggered is triggered by the the model that you select if you have on a simple you know let's take a happy path here right you have three you could have three different or two different Che devops change models one is for a three-step verification process and one is a two-step verification process and when you set up that pipeline Joe if you just I mean maybe just going into it you could the um the pipeline set up you can pick the model right so what every time that pipeline fires will fire a certain model of change and that will make sure that a certain flow fires when that pipeline fires right so pipeline model flow that's one way of doing it also in the near future with change we're looking at some enhancements around templates and around uh something called the action framework beyond the scope of this call which allows a bit more flexibility around the creation of tasks and some logic around that so there's a there's a few things that that's to come right that's future looking but for right now you'd probably have a couple of different models that have different seask type dependencies on them that would fire according to workflow um and then of course you can put decisions in the workflow if you want as well but it seems neater if it's uh to handle it with the m and by doing this you could create the change request at any particular Point within the pipeline yeah you could always do that I mean we recommend creating it right before the production deployment because most pipelines don't make it to Productions and you only need a change record if you do go to production so you want to put that change request right before the production deployment understood we have team however that create change requests first in order to use the change request number and the C task number as tracking for their code branches so consequently they're sort of doing it maybe backwards they want the change first and then they'll populate it later whereas other teams will wait and do it as you suggest and I would say best practice is to wait until after or at least to the point of uat where you know what you're going to put into production to get that change moving but you know teams do things different as you pointed out earlier so we're dealing with a couple of different scenarios here on when things should be done and how many things should be created So yeah thank you I appreciate your time for that thank you thank you yeah thanks for the question um I think Jo I'm not sure if you wanted the you more demo you want to show or that's that's there was one more thing I wanted to show and that's basically as an operator an alert comes in and and from that alert um you know service now is very good at saying okay uh this is the configuration item that's impacted by the alert maybe you're running a like uh data dog or something that's sending events to service now and you get an alert and it's it's saying okay this is what's impacted we can show you what changes took place right and and these small incremental changes now you see a whole bunch of them here look at the most recent one it'll give me the actual you know it'll help me determine root cores very quickly right because I can see okay this happened right before the incident this is most what caused it I could drill into the actual commit record uh in that uh change record right because we're capturing that from the git repository I can go in there and see um what uh line what file was touched and then if I go into that record it will actually show me the uh the change to the line of code right even the code snippet that was modified so I could you you know a developer can then use this information to go and and troubleshoot the problem and very quickly resolve it and that's and that's the game here right is to try and get these uh these alerts resolved quickly and and to be able to just have a stable environment and improve service availability so that's the last thing and uh if there are no more questions uh Greg I'll hand it back to you to wrap up we had we had one more good question that came in there which was about if you look in the questions there's a question about um digital product release and devop change velocity integration so it's FR that's an excellent question let me see if I can do that in a minute show you that yeah it's an excellent question because uh digital product release is a brand new solution from service now for actually you know we talked a lot about the policy in the change request well digital product releases focus on release Readiness even before you deploy a production just the process of you know building code and making sure things get done correctly and is the code ready for release right and what we do um as part of that and I'll and I'll show you an example of release is uh we execute that release uh with the assumption that you know it might not all be deployed all at once so you might have to have multiple change records so here's a release that's you know we're going through all the tasks and so on um and you might have change records here oh this one doesn't have let me find another one uh that are part of that release so we relate that those change records to the release itself and and it could be for a few different reasons right I don't like I'm sorry so you might have um you might deploy multiple builds as part of a release and those change records will show up but you might also deploy the multiple environment as part of release so you might have multiple change records there in this case we're relating all the changes to the release but still making sure that the release is ready to deploy so that's just a taste right that's basically the relationship if uh if you're familiar with DPR that's the relationship yeah we have one more that came through in the chat from bill so where SL when do you identify CIS for the change record that's yeah so that's done as part of the onboarding of an application um when you uh create that uh that record that you decide where um you want to open the change right which step of the pipeline you want to open the change you say what type of change you want to open you could also say what configuration item are we um are we are we using to are we attaching that change too yeah so here's the record I'm referring to this decides when we open the change there's my configuration item usually it's like an application service or maybe like an environment you know of an application service and so on so that's that's where we open the change that that's where we decide and that's done basically at the pipeline level so usually you have multiple pipelines they might be impacting multiple CIS and and that's why you could decide which CI is impacted by that pipeline [Music] he I think that's that's everything we have a couple more being covered in the chat um anything else if anyone has any more questions please raise your hand okay um if not I think we can wrap there thank you everyone for joining oh bill you want to come up mute that's Bill yes I think I'm up am I am I audible yep another question is uh you know I'm the one who asked about the CIS and the date and time okay so people are doing work you want them to flow freely yet in the same vein you want to have make sure the Enterprise knows when you're doing work Auditors want to know hey when did you enter production blah blah blah I don't see you capturing that anywhere other than when it actually happens that's only if you've got that end of it automated too the release end of it right if if you're opening a change record basically the implementation state of the change record is when we allow the pipeline to deploy and after it finishes deploying that's that that's the time stamp you're looking for right when did it go into production that's that's all captured in the in the in the change record um the change record is basically marrying you know an artifact or a group of artifacts to a configuration item saying we're deploying these artifacts to this configuration item oh and by the way we've done all this validation as part of this process just to make everybody happy yeah does that answer your question is it what what yes and you're saying you're saying that that that date and time that's captured over there on the on the Azure devops and of the of the puzzle will will feed back to the change record and update that information there is that it's in the change record as well so when the pipeline is successful we record that last this is the interaction between the pipeline and the change record so you see all the details make it back to the change record pending decision it gets approved the change record will go from an Implement State once it's deployed to whatever the next state is in your change model usually the review state or the close State and that will be logged in the change record itself let me see if I have an example of that but yeah that's that's exactly how it should work so that that should serve as the record as to when this particular group of artifacts would deploy to this configuration item does that does that make sense it does but I'm going to ask another question and maybe one of those dumb questions is okay so it's really the the actions of moving the card on the board that tells you when something getss into you know is being reviewed in production and then being closed is that true yes that's true okay so the the the the date the date of when it gets closed and when you know you're saying is being used to say hey this is moved into production it's it's relyant on the people that are moving those cards that kind of determine that time and date right well if you're automating it then it's basically the execution of that pipeline yes I got you we're not see we're not that automated to that respect but even if you're not automated somebody should close out the change record manually then right well I like to me it's like when they move the the card on the board to closed that means this thing is done what I'm having a problem with is people sometimes you know that's just administrative work that happens on the back end we're not automated to the point where when the release gets done that kind of moves on that board you have to move that on your board yourself so I'm kind of getting bit by the people that don't close their their features um at the right time yeah so even if you don't have full change automation where you know when the the production deployment happens um we we close out the change record so you can still use the event from the pipeline to close the change record so that might be kind of an interim type of automation you could Implement before you implement full change automation yeah I got you yeah yeah I thought so actually but just wanted to verify thank you yeah that's it's just another benefit of having the integration in place you get all these events of things happening they're going to show up in your you know in the tables and you can make things happen based on those events even if you don't use this this specific use case there's a lot to there's a lot to be gained by just integrating the devops tools with service now and getting all the pipeline execution steps for example getting all the commits getting all the work items that triggered you know lots of other customers to do other use cases based on those events that they're getting no doubt thank you y okay uh Donna do you want to go we can't hear you if you're talking Donna is not on mute but I don't hear her maybe Donna will come back to you um Marcus did you is your hand back up yeah you can you hear me Y no um might be a silly question but never mind um we a lot of our teams they um use devops tooling such as Ado but they don't work in a devops fashion by which mean releasing little and often they're still tied to doing two we release cycles and stuff which is so you're losing half the benefit of what this stuff does um but one team that does work in a devops way in releasing little and often is is my team as in service now um um changing service now developing service now a new functionality this that and the other so we use the agile module in service now the storyboards and all that kind of stuff does any of this stuff you've been showing us lend itself to developing service now in that way using storyboards and so on yeah if you're using SPM um agile right those work items show up in our in our devops data model just like if you're using Ado or jir so it's it's the same integration we we'll pick those work items up uh from the devops data model you'll see the links back to those stories so again when you have those change records that get automatically open they'll link back to those stories to show exactly which change which stories are being the key the key difference though is that the thing that ties it all together is the pipeline so the thing that you know the pipeline runs and it pulls in all this information around stories and testing because it's the pipeline run that we're tracking uh the pipeline execution and and the service now deployments in almost every case don't have a pipeline so whereas Joe was saying we have the ability to track these and add them to a change um we can't do quite what we're showing here because you'd have to manually add them because that just isn't unless you have some way of of knowing what's added right unless you can maybe we can discuss it if the pipeline is the thing for devops that does that there are other ways um and we we can use the story information but we just don't have a pipeline for service night deployments generally some people do but generally yeah but the data is there right and this goes back change traceability use case if you're going to create a like a new change um you can use uh you can use data from the from from the devops model right but I think it's a really key thing though to reiterate maybe though is is that the kind of key to all this working all the things we've shown here there is a huge sweet of data that we can bring in through the Integrations and it gives you visibility of what's happening in those tools right in all the developer tools you've got but in order to automate that change creation and use what Joe's showing is in D exchange velocity that there needs to be a pipeline there right that's the key component that that needs to be there to make it all kind of tie together yeah yeah for sure I mean you you don't necessarily need a pipeline but you do need you do need to have it tied together and you do need to be able to say okay um this is a uh a devops change right and then once you do that uh bring it up again uh once you do that you can um there change we can then add devops data to it so even if you're not automatically creating the change I could you know if I know I'm deploying something that was built through I guess you you do need pipelines right because if you're building your application with pipelines you're going to have like build numbers and you'll be able to pick a certain um application and say hey we we deploying this application from this pipeline or you could do it by autofact version as long as the data is in the platform um you know we're able to uh then there's no reason why that has to be a devops change at that point because you're tying the data together manually you could be doing other other models of change you can be doing other types of change the devops Integrations bring that data in for a waterfall team that's using Ado or if if their stories are described in J it can bring the data through and you can manually attach it um so it's a question beyond the kind of scope of today's call yeah yeah it's it's another stop on the adoption Journey right to be able to manually create change using the data that will automatically bringing in from the tools yeah before you get to automated change you can do this first okay and then uh Donna do you w to give you one more chance here okay so Joe I'm G to share again there's one more question that's come up in the chat that I can't answer that maybe Joe will be able to answer um not one I've ever come across before so christe do you want to come off mute and just ask your question let me uh enable that I I can ask if you want here I just allowed her to talk you allowed it cool by there Christie okay so the question was um I think it was linking epic content rather than story content to changes correct could you I just happened to it popped into my head as we were speaking we're using epic content manager to move our changes through all these different Landscapes on their side um so we don't use our service now change management process that's outside of the scope and I was just wondering if this is a use case or no not at all um I'm not familiar with epic and the change management process there I mean this is really tightly integrated with service now change management and I don't really see a way to oh I want them to use service now change management but they don't want to have to re Keen just like as your devel developers oh I see they have to reenter manual changes and so we already put it here now got to retype it in a different module and it's not really adding much value yeah I was just looking for a solution yeah if we can get that data into the tables we use and I'm not familiar enough with epic to know if it has things like web Hooks and so on but that's generally the way we work so when things happen in these devops tools they generate web hooks service now processes the web hooks right so and and and creates the records that we need basically any user integration you create would require you to write the stuff that processes the web Hook from that particular tool okay thank you yeah and chrisy can I jump in here is this epic the healthcare product that you're talking about yes okay that's correct yeah it may be worthwhile to do a followup because uh deeply understanding how are you using it uh we've seen uh good traction from use case overlap with our digital product release and Epic that may be the answer here uh but uh without understanding uh further uh yeah maybe that's what we do Christie reach out to us and we go deep dive with the with your use case okay thank you sure great just say if uh it's just to to get started with this it's very simple um you can go into the store and install the uh devops change module on your instance you know in a subpro instance um then you can go through the process of uh connecting your tools and um bringing in um the data from those tools and and basically there's a guided tour that take you through it step by step to get your tools connected and so but it's it's fairly easy to get started at least on the first couple of stop on the adoption Journey which was uh you know bring the data in and and start creating change records using that data