good morning good afternoon good evening welcome to the first session of our digital product release uh launch and learn series I'm going to be your host for this series uh my name is Greg holis uh today we're going to be covering just an introduction to uh digital product release okay before we get into the presentation uh I'm sure you've all seen the slide many times we have the Safe Harbor notice so there may be some forward-looking statements in this presentation they're based on our best understanding at this point in time so I just don't take anything as set in stone as it could change let's start with a a little discussion about the um the evolution of release governments uh in the last 5 10 years there been a trend in application development at the Enterprise level uh what used to be an IT project has now become more of a uh product being developed by business units so development teams have moved closer to the business in that regard and this was out of necessity right uh applications have become the primary way that businesses compete with each other and being able to respond quickly to the business required these businesses to take control and ownership of these products however it is still responsible for governance so this created sort of this hybrid operating model where uh you know our customers had to focus on uh governing products and governing the release of products that they didn't have a lot of control over so this is what Gardner uh came out with a um some recommendations for this type of operating model and the primary Concept in this type of model is a trust but verify method meaning you give these autonomous teams the autonomy they need to be agile and move fast but let's put some God rails on it let's uh make sure we are validating and verifying at every step of the way and we're providing a validation especially when it comes to the Readiness of things going into production okay so the challenges associated with this are you know are many right uh in many cases there was a lack of automation you had a lot of products with interdependencies on each other uh the The increased use of things like microservices and uh architectures that were interrelated uh meaning that releases had to be able to ensure that everything was ready before they went from one phase to the next being able to provide visibility into this uh was a challenge and then giving teams the awareness that they are ready to go to production right that they do have all the necessary uh security scans and and and you know testing and validation documentation legal sign off all of that had to be accounted for so what we did was we we created a dedicated release uh app for managing these type of releases uh the other thing customers were doing were because all of this was happening separately from it the change process became overloaded so a change would be created and all of this validation effort was loaded into the change approval process and this made the change process you know very arduous and uh required a lot of um interaction between the teams uh that that flow things down and in the end it wasn't very agile they weren't able to compete with these applications the way they were hoping to so what we've done with this release app is moved a lot of that to the release process uh so that you can validate at each phase of a release and then when something completes the process uh you can go into production rather smoothly with a with a much simpler change record right U all the time providing a visibility into the you know each phase of the release so everybody's aware of of where everybody's at and then uh providing some automation uh making sure that if somebody says they did a security scan they actually did it you know no longer do we need to have an attestation that somebody did a security scan or they did this the uh documentation we could actually validate that by bringing data in from those systems and running policies against that data to ensure they're compliant and then of course having a process that's reusable over and over again uh and is enforced by it right enforcing the process from the uh Central it governance organization uh really makes it much easier it takes a lot of the uh uh the planning work away from the uh the product teams and gives it to the central it to make sure that each phase of this release has the necessary components okay all right so what are we aiming to do here uh is really provide a release process orchestrate orchestrator that's looking at not just the uh the the manual task assignments and making sure tasks get done by all the different stakeholders but also providing a a way of uh uh ensuring compliance within with with automation right with uh with policies uh so validating lease Readiness with minimal overhead without putting a burden on the development teams without putting a burden on the governance team that's what the solution is all about and this is how we uh how we we're going about this we created a uh a product that manages relief release life cycles okay so what that means is you will define the phases of a release and there could be different types of releases different types of releases for let's say uh a major release that you know comes out once a quarter or half you know once every six months or you might have a minor release and or you might have an emergency break fix release or a patch and and those could be a much simpler process uh and each of those releases we call them release templates are going to have uh tasks and policies associated with each phase of that release okay and what we're doing is we're ensuring that everybody can see uh what phase they're up to in a release what tasks are outstanding and what policies are in compliant or not in compliant and this is the visibility that we're providing to all the stakeholders and we're also notifying folks when they have a task due right so this is all part of the underlying task management that the platform provides and we're integrated with that and it works just the same way as if you get a an incident assigned to you or a change assigned to you you get an email notification so you know you have to complete a task uh and the visibility we provide ensures that everybody's on the same page and knows you know what's keeping this version of this product from moving to the next phase or moving to a production deployment uh the other side of this is some technology that we've had for many years now and that's the uh the devops data model so we have a product called devops change velocity we provide uh lots of data from devops tools and these are tools associated with planning like jir and Azure devops and uh git repositories right so we understand when changes are being made to application code and then you have pipeline tools like Jenkins and GitHub actions and Ado uh pipelines and so on so all of that data makes its way into the platform so a lot of these tasks you may start out when you first adopt this solution uh these tasks could be manual but over time uh we can actually automate a lot of these tasks and what you'll see is you know today you may say okay here's a task let's assign it to somebody to make sure that the security scan is done however we have the data we know from the pipeline that the security scan was done and whether it was successful or not so we can eventually replace that manual task with an automated policy and this is the way you can mature uh through the adoption of this uh digital product release so that brings me to the next slide is you know what is an adoption Journey look like well first we want to provide these capabilities to uh provide visibility and to streamline and track all the different manual tasks right because we know in any release there's a lot of there's a lot of task being aside to a lot of different people and you want to be able to uh essentially see where every step is at so this is this is taking place uh within service now and all the users can have visibility into this and maybe if it's not necessary they don't have to log into service now but they would still get access to the task update dates in in things like Microsoft teams or in email for example and see the status changes of those tests uh at the next level maturity and and what I'll do is when I go through the demonstration I'll go through these uh you know these the phases of the maturity model one by one in the next phase of the maturity model we we we integrate with release planning so we know most of the work items that get assigned to developers are in tools like Ado boards and uh jira for example and uh you know even GitHub issues so we know that when developers are working on something for a particular release that's the task associated with is coming from these tools so we integrate with these tools so we can track those work items the user Stories the epics the uh the defects and so on and make sure that each release the scoping of each release will contain uh the the the defects and and the enhancement requests that going to be part of that release and this is a very easy way to know and and as a stakeholder you might want to know hey when is my bug going to be fixed you know what release is that coming out and when is that going to be deployed to production this is information that you'll be able to provide those stakeholders now um as I mentioned earlier a lot of these uh tasks can actually be automated right that means is you don't have to have somebody you know receive a task assignment and and sign sign off that they did it we can actually go and and and and see if if the task is complete without assigning it to somebody and in many cases those tasks get done in an automated way through pipelines so what we're really doing is providing a mechanism to ensure compliance and ensure at each step of the at each phase of a release that all of those uh policies are in compliant before we move to the next phase okay and then of course being able to define those policies yourself we Prov oh about a couple of dozen or so out of the box right that's integrated with our devops data model but you can create your own and you can create your own automation around uh around these tasks and these policies so so that becomes you know once you've reached that point you're at the highest level maturity and uh you can continuously improve your release process okay so from that I'm going to move over to a uh a live envir and first I'm going to show you we talked about the two aspects of the hybrid model right so you have governance on one side and then you have the product owners on the other I'm going to start out with um the governance side so Andrew Jackson is a release administrator that's responsible for actually creating releases I mean creating the process around releases defining the release process defining the policies uh ensuring that that product teams are following those policies and so on so as a release administrator uh they create and manage the release templates okay so what does a release template look like I'm going to jump into one here uh this is a major release template and what you'll see is um in this template we're going to have phases tasks and policies so let me show you a more visual view of that and so you can define the phases how ever you wish you can give the phases whatever names you want and in in this case this is what we call a Time bound release so that means each phase has a a designated duration okay and that means when we reach the end of that phase and and you know if you start the release on a certain date five days later that phase is going to end and we're tracking all the tasks and the due dates associated with that phase okay so we want to make sure that those tasks get complete within that duration and then you'll have phases like the planning phase the development phase uh you might have a packaging phase again you define the phases and then for each of these phases you're going to Define tasks that are associated with these phases okay so in the planning phase we want to you know scope out the app identify the Stak coders prepare the documentation identify potential risks these are all happening before we even do any development work in the second phase we do development work and we start looking at making sure that the testing is complete the the the packaging is complete and what you'll see is some of these pH some of these tasks are actually what we call an approval task they need somebody to approve them some of them just get assigned to something somebody and they'll they'll receive an email they'll check that they completed it and and so as you move through the different phases you'll see the different tasks associator now approvals require somebody to approve it now because this is a template we don't want to hard code who that approved is because we want different product teams to be able to use this template and so we have a mechanism for actually looking up who that uh approval person might be we call it an approval definition so here you see I have different types of approval I have cab approval I have a product owner approval uh and then I have a product owner's manual man manager approval we could drill into that and I could show you what that looks like what we're doing is we're going to take the product owner uh the digital product record that's associated with the release right because every release is related to a digital product and we're going to say okay this is a approval action of a user show me all the user Fields uhuh that are associated with this digital product record let's find one okay and now let's find the manager right so we're dot walking from that record to the user record that's associated with the manager that's the reference field we might actually want the manager's manager to approve it so we could do that again we could we could dolor from the manager manager to the manager's manager and now this becomes like a higher level of approval uh for this particular task and that's what gets assigned uh when that template is executing that's who will get assigned that task and what this does it helps us you know create these reusable templates uh where we can do lookups uh as part of the execution of that template of who actually needs to approve something uh who A test should be assigned to and so on okay so that's the role of let's say the release okay now I'm going to switch over to one of the product owners okay and what you'll see is the product owner is in this case the the product owner has actually seven active releases going on right now uh expected to complete soon so we list those out for the product owner so they can see what the status is what the progress is uh for all of those releases uh we could drill into some of these releases and see the details but at a high level we can see all the approval tasks that are outstanding all of the uh the manual uh tasks that are outstanding uh but also as a product owner we're responsible for actually planning the release right so here's a release planning page where we can see these work items come into the backlog okay and these are coming in automatically I'll get back to this in a minute but we're going to actually drill into one of these releases okay and actually let's drill into the summer patch this one just initiated today uh just kicked off a new release and we can see uh basically everything we need to know about this release there's a a release start date of yesterday uh we expect this release to end in 48 days right so this is based on a release template of 49 days and each of these phases has a certain amount of days associated with them uh I can drill in that I can see all of the policies and approvals that would be associated with this release let's go ahead and look at the uh release execution here we have uh tasks and policies associated with each phase of the release so as a product owner very quickly I can see where we are in the phase of the release we're somewhere at the very beginning and and what tasks have been completed or not this one it just started so I have one task that's a work in progress if I drill into that task I see it's assigned to John Chipley John Chipley would have to log in or they would get an email that the test would assigned to them so this is part of maturity level one we're just managing the phases of a release we're managing the tasks Associated release we're not really dealing with policies at this point but uh it's just a very quick and easy way to get started with uh digital product releas so let me go in into uh impersonate John okay so John now you know logs into service now they get to their home screen they see they have the task assigned to them they can go ahead and uh marck that task as uh complete uh and close it out when they completed it and then that would be reflected back in um E's dashboard right so uh and this is the way you track the manual test across the various releases okay so uh so that's that's really maturity level one as as we just talked about just tracking Andis and and tracking and visibly uh making sure that things are getting done uh now let's talk about release planning I showed you this a minute ago this is the um the release planning dashboard and what you see here is you're going to see lots of uh releases lots of work items in the backlog where are these coming from in this case they're coming from from jira so if I uh click on any one of these uh it's going to give me some details about the work item this one's linked to an Epic from here I could actually click into jir and see more detail right because we're just bringing the Header information over but if you want to see all the work notes and so on that's all going to be tied uh you know all of that detail is going to be in jir often as a product owner I'm I'm not interested in that level of detail but what's important is that I can see um within my release planning which work items are going to be part of which release so I could see in the summer patch we're just doing some bug fixes and some security updates and so on that's part of the summer patch that I'm working on here uh I think uh and in many cases you know I C so as a product owner I could actually designate which uh work items and which product features end up in which version so I can just drag and drop them however usually more often than that this will be done in the planning tool this will be done in Ado boards this would be done in our own SPM agile solution right uh this would be done in jir however uh we have the ability to do it here if that's not the case Okay so that's really uh once you start bringing in this type of information from those tools now you've reached maturity level two uh and now you could you could not only track uh releases but track the completeness of these work items as part of that release I think Greg pause here to see if there are any questions that we can uh answer before we move on to the next part of the demo let's see most are getting answered uh throughout the chat okay great yeah there's nothing directly so we can we can keep going I think great okay so that completes uh maturity level two integrating with the planning tools bringing the the um the product features and the bugs and the defects into uh digital product leas so we can track it all right now let's talk a little bit about policy okay so policies are as I said before are queries right they're queries to make sure that things get done and what we're doing is we can log in uh to these tools directly and see the data so for example I can go into uh Ado and see okay did all the integration test passed I can go into Jenkins and see did the uh security scan run or I can use the devop data model make that data available to these policies and then we can we can uh run these in an automated way okay so what we do is we assign these policies to a release and I'll show you what that looks like here uh let me bring up this one here in this release we have lots of policies uh and we can see um as the release executes at various stages of the release we're going to make sure that these policies execute and are in compliant you see so what happens is as uh builds are being created in build pipelines those results propagate into service now and then when these policies run and these run on a fixed interval say uh once a day or once every hour even to make sure that they're in we can see all the stories have Associated commits you know that's a policy we want to make sure that when folks are committing work to get that those work items get assigned to stories and and I mean those commits get assigned to to stories or or defects and so on so we're making sure that developers are following best practices uh we're making sure that security scans are running smoke tests are running and all of this data is coming to us in real time I'll show you an example I'm going to rerun the policies because I just ran a a pipeline here and in my example today I'm using uh integration with GitHub actions I have two types of pipelines one that builds the autofacts and another one that deploys the autofacts uh you can see in the previous run uh we we we created artifact and everything looked good and how do I know it look good well we actually propagate that data to the release dashboard so if you look at these quality at this quality tab here we can see the actual uh results of the scanning from the autofacts and we can see uh that all the the unit tests pass for example and if I had functional test and performance test and so on all of that data would be propagated here some of this data is coming from tools like sonr Cube some uh tools like veric code and and all of that is part of the devops data model so we have access to it the propagated here I'm going to run another job here and in this case uh in GitHub when that job runs uh we'll see that you know maybe things didn't go so well okay so the scan didn't complete successfully all right so we're going to let that run takes a couple of minutes uh in the meantime I'm going to show you some other capabilities of the dashboard here uh and it's also okay so we see all the uh from the release overview we can see uh how many tasks have been completed 29 have been completed five of them are still open I could drill into those uh five and see a list of them and then I can make sure that they're assigned to the correct people and so on uh we can see again the uh execution of the uh policies uh I'll come to change requests in a minute uh that's another capability uh what we've done is integrated with um deployment pipelines and if you're familiar with the uh devops change we can create those changes in an automated way or I could actually manually create those changes associated with the release right so anytime we deploy something I say okay let's manually create a manual change I'll do that from here uh we can do just a normal change and that's going to now be associated with the release and um and then in a minute I'll show you how we can actually deploy an automated change change save that and now that change will become part of this release so you might have you know multiple changes Associated release with a release for you know for several reasons right you might have uh different production environments and each time you deploy to a production environment let's say you have one in Tokyo one in New York each one is going to require a change record because each one is a different uh configuration item right in in in service now so you know one day you might deploy to Tokyo the next day you deploy to uh Colorado and then you have two different change records so you you'll have different change records Associated release but often with you know in the case of let's say continuous uh continuous deployment what you'll have is uh as features are ready and as builds are complete if they went through their testing process even before all the product features are complete you might deploy two or three features and you'll get a change record for each one of those deployments so that's why you can see a lot of change records for release would accumulate okay it's just a more Modern Way of working a more efficient way of working to track uh uh changes in deployments uh in an ongoing manner okay so let's go back to our build uh this one just completed here um we track all the uh builds in in in service now as well so I can see in the release artifact I can see um that build number here uh let's refresh this should be coming in as 169 I believe was the last one and that would show up in the uh question is this right we'll give it another minute might be showing up in pending there it is so it's it's it's uh the autofact registration is pending so so what that means is anything associated with that autofact uh the build the build results the unit testing the functional testing will all be part of the data that's available to us for compliance and for uh for policies for executing policies okay so as those execute and as the policies run we're able to um validate those policies when they run okay so now we've created a build and let's say we want to do a deployment uh those deployments are going to run okay as a separate Pipeline and now you know this is basically uh let me see what was that artifact here uh believe we're up to version one one B pending okay we I'll go ahead and what I'll do is I'll deploy this one and we'll go ahead and deploy the uh the previous one so this will kick off a deployment Pipeline and keep in mind that this deployment might take way you know might take place a week after we build it right because there might be various stages uh in that but we're tracking everything associated with that artifact so now that we go to deploy it it's going to create an it's going to automatically create a change record so I can manually create the change record or we can use the um the integration with uh with the devop data model to automatically create those change records okay any other questions anybody from the service now team like to add anything at this point we got quite a quite a group on from our product management team also I don't at the moment uh we're answering a bunch of QA uh Q&A questions so definitely if there are more questions coming up um place them in the Q&A where we're typing answers as quickly as we can great if there's uh anything interesting on that uh Q&A board that you want to bring up and share with everybody now might be a good time to do this I'm just waiting for my change record to be created yeah so um there was a question that was just asked about the relationship between change requests and the release itself and uh so uh by the way everybody since I started talking my name is Colin O'Brien I'm one of the inbound PMS uh and bology is also one of the other inbound PMs and he and I have been answering a bunch of questions along with kayin on the outbound side uh but on the the change request itself there was a a a question about how the relationship worked and we are the way when Joe opened the change request manually and also when change requests are opened through devops change velocity um automatically we have added a reference not to the release itself but to the version of the product that is being deployed um and the thinking behind this is that the change request itself like when you open a change and reference the configuration item like an application service um that application service is what's changing but what's changing about it is a new version is being deployed so by having the connection to the basically the version of the product it means that the change can not only describe what is it like where are we deploying it but what is it we are deploying so that if an incident comes from a change um or if there's some outage caused by the change we have a connection that says here is what we deployed and the as you get into the the further ends of the like the maturity curve that um that Joe is going over in the PowerPoint uh we also have through these Integrations the ability to then say here are the artifacts that were built from that version uh here's the code that was was a part of that deployment here are the test results from the pipeline that ran here were the stories no matter where they were in SPM or otherwise so it gives a lot of uh long-term gives a lot of traceability to help with root cause analysis or to help with restoring service faster because you have all the details that come off of that uh version of the product um so that's how the connection works with with change management yeah and these changes are so comprehensive uh you know basically they're created automatically but they answer all those questions right of who what why when and how uh we can see uh actual code details for example uh little Snippets of code showing in the change record of what actually changed now not everybody likes that level of detail you know you might not want uh application code inside your change record for a lot of reasons right you can turn that off okay so just uh keep that in mind but the idea is that these changes get created automatically uh they they get tied back to the release and they tell you uh who made the change from the commit record why is the change being made well we're doing it to fix a bug or we're doing it for enhancement request that comes from the uh the the user story or the defect work item in SPM or jira uh when is it going to be deployed that's part of the change record as well and that ties back to the release uh the the release planning so all of this is uh is is is is tied together and uh you know and this this basically brings us to the advanced automation this level four of our maturity model where we're creating these changes automatically and we're uh driving that integrated uh risk assessment so you know it's part of that change approval policies for example we can make sure that those changes aren't deployed if if the stages of the release weren't complete if there's some compliance issues if there's some policies that weren't complete right all of that data would be available for those change of rule policies so uh that's all I have from a demonstration capability uh are there any questions or concerns or comments that we should spend a little more time on so one thing since we have a little bit of time that um I was thinking there's also a question in the Q&A this can help answer uh since so many of the respondents to the first poll were about leveraging release uh release management 2.0 um so there's a question about you know is this replacing release management 2.0 uh especially because we're focused on the software side and not Hardware uh releases at least not not yet um so this is effectively the replacement for release management 2.0 if you are using release management 2.0 you have probably uh customized it quite a bit at least that's been my my experience um so if you are using it for other types of releases it will still be there although we are uh we are ending official support for it starting in Xanadu that's the the time of when it will start now we've also had I think six cases opened over the past year uh and we will be be supporting it for quite some time like so long as your contracts uh are you know you still have release in them so I don't foresee that if you're using it for other types of releases that it will be much of a change for you uh that being said we are investigating how to use the concepts that we have built into DPR uh for other types of change so I've been interviewing customers for different things outside of software and there's a lot of overlap in Concepts however the hardest thing that we have done as we've been building digital product release has been about the experience making sure that you have the right information for that kind of release and so as we're investigating supporting other kinds of releases like Hardware um also I've been asked about managing service releases uh as well as we're learning about that a lot of the concepts them to hold but the experience would need to shift and we're learning what that would look like um so if things like Hardware based uh release management is of interest to you and is a is of importance then please reach out uh so that and I and I have the people that that indicated in in the Q&A so I'll be able to uh track you down and ask questions um but definitely you can reach out so that we can that that'll help influence our road map on what would that type of release look like so uh digital product release is available uh as part of the itsm Pro license right so if you have itm Pro you're entitled to use it however even if you don't have itm Pro you can still install it in a subr environment and if you find it you know it it provides a lot of value you can uh upgrade your license to move it into production but anybody can install it in subpro and uh you can start experimenting uh with the capabilities and you can engage with us further uh through the community