I think we're good to get started well good morning uh good afternoon good evening everybody wherever you are in the world welcome to this live on service now event talking about digital product release uh my name is kayn Castell I'm one of the speakers today we'll get into speaker intros in just a bit but we have some housekeeping slides that we're I'm going to walk us through before we officially get started with the presentation uh first is a safe harbor notice uh this presentation may contain some forward-looking statements based on our best belief belief and assumptions at this point in time uh but please know that uh there are uncertainties around uh forward-looking information these things may change so just don't take anything uh as as locked in stone if it's forward looking second is uh we want you to join us at more future webinars and 360 events today's session is a part of live on service now it's a curated event series to help connect you with service now experts and peers that can help you deploy your products and Achieve value faster so we hope you join us again at another webinar or 360 exchange you can see the schedule by scanning this QR code right here or please use a uh the link that Greg will post in the chat give you all a minute in case you want to scan this may not a minute 10 seconds okay and uh final housekeeping slide uh we we do have time at the end of the session for Q&A so um I believe you aren't able to come off mute but please use the Q&A button at the bottom of your screen in the zoom to ask questions along the way we'll be monitoring that uh trying to aggregate uh common questions and answer those at the very end this presentation will also be recorded um so if you want to share this with a colleague you want to review it later look to our service now Community for uh this presentation and after the event uh we also are really looking forward to your feedback so we'll be sending out a survey to get your feedback please please look out for that and fill that out okay so jumping into uh the agenda for today going to start with some speaker introductions of who who you're going to be hearing from then we're going to talk about uh some context with the evolution of release governance and from that dive into digital product release what it is how it works and then you'll see a demo uh from Joe for digital product release and then we'll have Q&A so for your speakers today uh like I said my name is kayin castelo I'm bound product manager with itm I've been at service now for about two years and my primary focus is on our products that fall within our modern governance space so that is our new release management product digital product release what we're talking about today as well as devops change velocity Joe I'll hand it over to you to introduce yourself sure I'm an outbound product manager as well in itsm and I uh focus on our devop Solutions uh devops change velocity and now digital product release looking forward to showing the solution nice to are than Joe Greg over to you hey everyone I'm also gregis I'm also an outbound product manager with an itm focusing on the same products so our devops products as well as a digital product release great all right with that let's jump into it so when we speak to our customers we see that many are in a state of flux when it comes to Enterprise governance it's becoming less common for it to have a command and control forceful hand uh and instead we're seeing customers evolved to a more trust but verify form of governance where it enables teams to do the planning building testing deployment uh and and running their own applications and services more autonomy more autonomously uh within the guard rails and visibility of it with this shift customers have expressed the need to adopt uh to adapt and properly enable their growingly Federated teams to maintain that digital contract with it to drive resilience and compliance focusing on how this applies to release management specifically the traditional method of release revolves around a Project based way of working so if you take a look at the the left side of this visual you'll see applications and features are bundled together and released together as a part of a larger release package that's managed and validated by a central release team as organizations modernize and adopt more agile devops practices release has evolved from this traditional Project based way working to a more product based way working and in a product based way working we see distributed autonomous teams doing the planning building testing and deployment of products on a more iterative frequent basis this has a number of benefits very similar to what many of you may be familiar with from a devop perspective where there's faster Paces of releases quicker feedback Cycles as well as an enhanced ability to Pivot but it also comes with its own set of challenges particularly for it uh where it's becoming more difficult to have visibility into these discrete releases and it's also harder to ensure compliance across all these releases so as a whole we're seeing really shift away from this traditional project-based way of operating and now we're observing Central teams more focused on Def finding the right guardrails to enable product teams to get their work released in a compliant manner when we speak to our customers we also hear four key trends that represent the challenges around their release processes uh the first is around a desire for more automation as software products are becoming more complex release validation particularly if it's manual and to be honest it it is is often very manual uh takes more and more time so they they want more automation the Second Challenge is around a loss of visibility this is the one I I briefly discussed in the last slide as as organizations are digitally transforming and becoming more agile adopting DeVos practices we're seeing product development move into a discrete line of business teams and it is losing visibility into those releases on the other side of the spectrum the the product teams themselves that are becoming more distributed without proper Guard rils from it are unsure when they're ready to release and how their work is measured uh so this could lead to uh them releasing a code that's not fully compliant leading to issues down the line or perhaps they're trying to figure out when they are ready to release and that's actually delaying them uh in their release the fourth challenge is around change becoming arduous this is something that we've seen with uh actually a number of service now customers is that because uh service now has not offered a truly capable release product up until digital product release many customers have actually ended up augmenting their change management process to accommodate release so this has made change very overloaded and arduous with the number of fields in their change forms to validate release Readiness from these challenges we saw an opportunity uh first and foremost to fill the Gap within our product portfolio uh for itm with a capable release product this is digital product release release management B2 uh was our Legacy release product was essentially just a set of tables but there's no real workflow on top of it DPR is launching with parody of of that release management V2 product and also has the most requested features we've heard from customers using release management V2 uh at GA so it's going to have a great user experience it'll have released templates that are reusable and configurable and it will have the ability to connect devops tooling with digital product release Central it can also gain end visibility and to release Readiness across the products they're being delivered uh we're going to provide the ability to automate leveraging policy checks uh using our policy is code engine that help validate compliance and assure governance across products and then uh for those release teams we're going to help uh them understand when they're ready to release by applying reusable centrally defined release templates that can apply release policies across phases to help those teams certify when they're ready to release okay uh with that we want to uh see how that uh context and problem statement resonated with you so we're going to launch a quick poll great if you could help launch that poll great uh so first question is around if you at yourself are seeing that shift from a project to product based uh release at your organization second question is around which of the challenges that we've highlighted have you experienced perhaps you've experienced all of them maybe you have experienced um none maybe there's another changes that you you have experienced that we didn't call out we'd love to to know what that is uh and the third question is around what you use today for your release process we just give us another 15 to 20 seconds to get responses and then we'll show you all what you said a lot of great responses so I'm going to end this poll and share it so uh it looks like the vast majority of You Are uh have uh seen this shift or have already made this shift about 80% of you um the the challenges that we we shared resonate with with the vast majority of you that's also great and it looks like most folks on this call are actually using very manual uh a very manual process to manage your release process so hopefully as we introduce digital product release it seems like a a good solution that you would be interested in in adopting all right so let's jump into uh what dig product release is so our vision for digital product release is to be the release process orchestrator and the key word there is process that'll help enable product teams to consistently plan and deliver new versions of products by providing visibility into the release process and automating the validation of release Readiness while incurring minimal overhead DP DPR is not is designed to help organizations Advantage the process in which they ensure products are ready to deploy but what it does not uh Encompass is the capabilities to the actual development testing and deployment so that's why it's really the the release process orchestrator we're going to spend a decent amount of time on this slide this is really the slide that helps uh demonstrate and uh helps you understand how DPR works and how DPR impacts release so just to reiterate DPR does not incompass the capabilities to do the building testing or actual deployment of a product what it does do is tie these different release phases together in this example from planning through deployment as a layer that validates when a product is ready to progress from one phase to the next and we do that uh via policy checks What policies are are their data driven validation checks that will happen automatically they'll run on an hourly job that'll leverage data from both within service now and also thirdparty Integrations I'd like to think of policies as Gates uh that will deem when a release is ready to progress from one phase to the next only once all policies tied to a particular phase are compliant can a product move to the next phase in this visual you'll also see a concept of tasks tasks are designed to be explicitly looked at or performed by a person so think of them as manual checks or approvals needed to cover actions like gaining legal approval or getting design sign off we're not using tasks to to determine if a product can progress from one phase to the next that's only happening via policies that said there will be a policy that will check to see that all tasks are complete and this could be Associated to one a few or All Phases we actually anticipate uh most customers looking to adopt erpr initially well will rely heavily on tasks across their phases to to validate aspects of Readiness and then use these policies that validate task completion to progress forward through their releases at the bottom of this visualization you'll see many of the third party cicd planning orchestration testing uh security and monitoring tools that can be leveraged with DPR in these policy checks DPR is using the devops data model to integrate with these tools this is the same data model that devops change velocity um uses to integrate with tools and uh we're fortunate to leverage all of the the learnings and Investments over time and that experience from devops change for DPR so it's a pretty good streamlined experience right off the bat uh we do want to call out that DPR does not require devops change to actually use um but we we actually see DPR as the more more the more likely entry point for most customers to be introduced to the devops data model so you can begin integrating with your cicd tools getting that data into service now and then leveraging it um across your workflows so to summarize how uh this works uh one more time in in the way that I like I like to think about it is traditionally what customers have done is just before they both deploy uh code to production they have a change request that'll be very long it'll have a number of change Fields custom Fields that'll validate release Readiness across a variety of aspects and if anything was found wrong in that change form would kind of be a struggle or a fire drill to figure out what went wrong when it went wrong and you have to contact a lot of teams and that change change would be open for pretty extended amount of time what we want to do with digital product release is we want to take all those custom validations that are happening as a part of that change request and instead shift them left so that they occur in the phases that they actually happen so that the validation is happening throughout the release and then by the time you progress to that release and you get to the point where you're creating the change instead of a very long Uh custom change form you'll have a change form that will reference digital product release to see if this release is compliant if it is compliant then that change is relatively simple to uh view approve and then uh Implement so you can deploy that code to production so that that is how we view digital product release working impacting release and also potentially simplifying your change process so to recap question about the DPR Works alongside existing change processes does yeah soorry was that the was there more to that question just how does it how does it work uh well we see DPR as a as a if you leverage change models you can actually uh create custom change models that will work with DPR as well but we we see DPR as an opportunity to actually simplify most folks existing change models because typically what we've seen is a lot of customers have uh they've made change kind of do a lot more than it was intended to do and a lot of the release validations that should happen throughout a release are happening in a change so DPR can help pull out a lot of those validations to happen throughout a release so that you can actually simplify your change process hopefully that helps all right um so we're about to the demo just got a few few additional sites here uh so to to recap digital product release ism's new modern release solution that'll help enable product teams to plan and deliver new products consistently with low overhead guardrails defined by it so these are our release templates and policies and uh DPR is going to help provide the benefits of governance while limiting the headaches that it often incurs on teams one of the key pieces of information that I haven't yet mentioned is how DPR is licensed uh DPR is going to be included as a part of our itm pro package so if you have a skew with itm Pro or Enterprise you'll be able to download and use DPR today uh one other important note is that the minimum patch version you'll need to run DPR is Vancouver patch 5 so for those who are on Vancouver or planning to up upgrade to Vancouver you'll be able to use DPR uh even though it's it's launched as a part of Washington uh before we jump to the demo I did want to share some customer validation proof points that we've observed for DPR uh the theme of the two quotes you see here is that DPR solved an acknowledge need for for these customers that they were planning to to build custom themselves and instead they can they can leverage and use DPR and then also benefit from our continued investment in the product when we built DPR we we engage closely with a number of design partner program customers to co-develop DPR uh and from these customers uh the majority of them actually were were quite aligned with our MVP that launched uh with Washington and of those uh several are already on their implementation Journey um the remainder that weren't uh aligned to our MVP are aligned to scope on our road map and intend to implement DPR when when those features are released so uh the key takeaway is there is that DPR is solving the need of of many of the customers that we work closely with we've listen to their feedback to to co-develop it with them and then we have a lot of key enhancements planned uh over the next several releases to keep building the capabilities of DPR so that these customers can grow with it and use it all right final slide before the demo uh in the upcoming demo you you'll see um a a narrative that focuses more on the release execution uh from a product manager and release coordinator Persona so this will represent more of what day-to-day users of DPR would do when it's up and running not a core focus of this demo will be the setup experience that our teams put a lot of time and focus into streamlining uh at the ga at at GA when we launch DPR so we want customers to get to First value quickly with DPR um as you can see in the screenshot here DPR uh is launching with a guided setup experience that'll help walk admins through how to define the release process uh when release releases should happen and connecting to external Tools in DPR additionally we're launching with a number out of the box excuse me out of the box policies that customers can use to automate the release compliance and Readiness checks so with that Joe I'm going to hand it over to you for the demo great uh will you going to bring up that slide to show the persona okay fantastic so uh what we're going to take you through is a demonstration of first uh how uh a a release manager like Andrew or a program manager or perhaps somebody responsible for the governance of releases will be able to create templates that ensure certain tasks and policies are followed uh this is to make sure that we have centralized governance over the release process still allowing autonomous teams to manage the releases themselves but to sure that certain things get done for example we want to make sure there's a task that ensures a security scan is done for certain types of applications uh that would be Andrew's responsibility to put that task in the release template okay Eileen on the other hand is a product manager or a product owner okay uh she's responsible for uh one prioritizing features of the release so I'm going to show you uh how we do that as well as tracking the execution of the release and making sure all those tasks uh get done and then uh we have an engineer who who's not uh logging into service now at all is remaining in her own tools in this case I'm going to show you in GitHub and GitHub actions how she's creating uh uh you know enhancements and Bug fixes and so on and and then driving uh improvements to the product itself and while that's happening in a passive way we are capturing that data and service now to help us track uh different aspects of the release so we'll take you through that okay so I'll go ahead and uh share my screen here all right so what you're looking at here is our digital product release dashboard the first thing I'm going to do is I'm going to go ahead and impersonate uh Andrew who is our release admin responsible for the governance of the release and what Andrew's primary job is is to make sure that there are templates that are applicable and available to all the different product teams okay and then make sure that those uh uh templates contain proper phasing and tasks and policies to ensure that uh the release uh not only happens in an expeditious way but make sure it's compliant with all the policies that are required so if we look at what a release template uh provides uh we're going to see first phases are defined okay in this case we have six phases now your release policy might might have four phases or eight phases right that's completely up to you this uh release template is customizable you could have multiple templates as you see uh we might have a minor release template we might have an emergency uh brake fix release template right but in this case the major release template uh we're going to show you we have six phases each of those phases will have um various uh tasks okay so I can show you the tasks associated with a face now difference between a task and a policy is simply this tasks are executed by people right these are manual steps uh a task is either somebody gets assigned a task to do something to check a box that they did it and now it's done or it's an approval an approval means that somebody has to approve uh or sign off on something uh and and the difference is with approvals we could actually look up who that approver might be we call these uh we call these approv definitions okay so for example if we go back to the template here uh and we see in our in in this task um the stakeholder is required the product owner's approval is required that actually is a record that will look up who the product owner is and send them that approval task okay and when they get that task they'll go ahead and uh approve it now uh just to show you what these approval definitions look like okay let's go back here to the approval definitions here's the approval for the product owner's manager and we can see um we start out with a an approval Source this is the record that we have available to US during the release and it's the digital product and then from there we can work from the owner or from any of the other fields to the manager and if we wanted to we could even go up one level further to the manager's manager right and say okay now we want a higher level of approval we want the manager manager to do this approval okay so that would define that approver and whenever that uh specific task was executed as part of a release that person would get a notification it could come through teams it could come through email and it would say hey your approval is required for this task to be complete okay so that's primarily what the release uh manager or the or the release admin is doing uh the other thing they're doing is uh defining and we'll go back to our template here uh is they're defining policies now policies are similar to tasks and that in order for the phase to be complete they have to either get done or they have to show compliance right so for example these are policies that actually will query data in service now in the data model to make sure that certain things are done it could be a legal sign off it could be that documentation was created it could be that certain CIS were created in the cmdb right uh in this case we have a lot of policies that are looking at the devops data model so if you're not familiar with our devops change velocity solution underpinning that is a data model that brings data from all the devops tools I'm going to show you examples of that so in this case we want to make sure security scans are done we want to make sure that uh unit testing is done performance testing is done integration testing is done all of that's done in the development process and that becomes a policy as part of the execution of a release of a phase of a release if this is the development policies during the packaging phase we have some other policies that we're checking this is all automated okay the big difference between policies and tasks is the tasks are manual tasks executed by people and the and the policies are are automated queries to see if something was done in in some other system or in the in the service now database now it's very likely that you would start out with tasks in your in your release process C that eventually turn into automated queries right so for example I'll show you an example uh where uh unit testing is being signed off by an individual I did the unit testing I check a box it's done however we can see based on the results of the actual build process in the devops tool if it was actually done and we could capture those results instead of having somebody sign off on it we're getting the data Live From the Source in this case the actual testing tool in the PIP pipeline okay so that's the uh Persona of a release uh admin basically ensuring governance of a release and now I'm going to show you what happens how do we execute releases how do we scope the releases I'm going to impersonate our second user ien okay that's fine and Eileen is responsible for a group of of products okay and here we see you know the state of different products uh and and from here we could also see uh the approval tasks that are responsible how many releases are in different stages and how many policies we're waiting for compliance right because we are uh exposing that data and propagating that data up to the dashboard okay let's take a look at this one product the uh the April release okay so I'm going to go and show you what that looks like from a product manager's perspective uh these are the three products she's responsible for and this is what CES uh let's look at the product features so in this case the product features are actually being sourced from a project management tool Jer okay so uh we're not creating the features and and adding them to service now we're actually tracking them in another product uh that could be jir that could be our own SPM solution right if you're using SPM we can track the uh the work items there it could be Azure devops boards these work items link back to those uh to those projects and if I was to open one of these I would see the link I could see the Epic that it's tied to I could click on this and this takes me right into the jira uh feature that's being tracked by the developers so the developers stay in their tool they manage their the work items here however we are keeping track of it in service now so we can see which features are going to be part of this release this is very important for stakeholders right they want to know hey when is my bug going to be fixed when is new feature going to come out this this dashboard shows them which features are going to be part of which release it also has a way for us to check off when a release is complete and that's another policy we can do is actually check for the completeness of these work items okay now these are the the managing of relases you could actually uh as a as a product owner I could actually move things from the backlog into different releases okay let's move this into the spring release and that will realign the uh prior it of that feature so now it's part of the spring release instead of in the backlog okay so that's one of the uh one of the responsibilities of the release manager is to make sure different features are you know the different releases are scoped properly and but normally this is not done in DPR it's done inside of these project management tools and we're just tracking it here okay I hope that's clear so uh the other thing that we're going to do is we're actually going to uh attract releases now now for example we have various um patches coming out eventually I could actually create a new release from any one of these uh seems like these all have releases created uh here we go I can create a release in this case I would use the template that was created by Andrew right by Andrew Jackson uh I can use that template to create a new release and that means that that particular release would follow that template okay so what you're going to see is here all the releases that are being executed right now I'm going to find let's go back to the dashb I'm going to find the um the uh April pre-release here and one thing you'll notice about you know this is the execution of an actual release one thing you notice is there's a lot of data about the release presented here uh first the release started back in February we're expecting it to be uh the final release Target date is April 8 now that's important because by by then we should have everything complete and be ready to deploy we expect the deployment to end on the 20th of April right so there might be a rolling deployment to various uh you know different environments and so on we're going to track all those deployments with change records and I'll show you that at the end but in the meantime what sticks out to me right now is my risk score is very high why is it very high well if we drill into the release execution we can see that um some of my uh tasks are not complete from the development phase I'm in the user acceptance phase right now at least that's where I should be however if we look at the tasks here and let me go ahead and clear this filter I see the unit testing has not been signed off on if I drill into this I see the unit testing is assigned to Coleman Cano and and and and Coleman should receive uh notification that they have to approve this task okay so if I was to go ahead and impersonate Coleman uh we would look at their uh dashboard and then you know they would they would have this task assigned to them and it would be one of the things uh this this unit testing task it even shows here as overdue they would have to approve it and then that would move it into uh into the phase and that would help complete the phase now again this task is not um doesn't have to be manual okay it can checking if a unit testing is complete is something we can do in an automated way so let me uh go back to Eileen and show you that policy that can essentially do the same thing okay so what I mean by that is um that policy can uh actually check the results of a build in a devops uh process and check the CC now we drop from high to medium because now that task is complete so we're no longer at risk of missing our release date okay let's go back to the release execution screen here and see that that task is uh should all be uh complete all my tasks are complete that's great so now I'm in the uh the user acceptance phase but let me show you also the policies right because I said that software uh policy compliance uh can be tested by actually tracking autofacts when they're being built um what you have now with devops is the continuous building of autofacts and in some case The Continuous deployment of those autofacts meaning we're not waiting for the release to be complete to actually deploy things to production this is a decoupling of of actual deployments from releases that we can track as well okay so we have a lot of flexibility here so let me go ahead and build a new artifact we see number 122 was the last artifact and we're actually tracking that here we see that in the dashboard if we go to the release artifacts I can see we're always using the latest version to run our policy if we drill into this we can see all the different versions that were built 122 is the last one that corresponds to what's happening in my GitHub environment here I'm going to go ahead and run another one and what you'll see is when we run this build we're going to now build 123 and if I've introduced any defects to this uh those defects are going to actually keep this from being compliant right and I'm going to show you that now that it's no longer compliant that compliance will be reflected in the results of this uh of this release execution phase okay so the task would would come back and show as non-compliant okay uh while that's running uh Kayla are there any questions we could jump on uh in the meantime that you might want to bring up that that are being uh asked in the feed here yeah I've been trying to answer many of them but we can answer some live um I think this is one that I've seen a few times what about now now type releases where we want to track service now upgrades in DPR can we get release notes from docs and import them to DPR release so I think the idea of supporting now and our releases in DPR yeah absolutely so what you have you know is if any data that's in the platform becomes available to use in releases and and and in digital product release um and and releases especially like uh sculpt application releases or releases to uh platform versions if you have separate tasks and phases you need to track uh that's fair game including you know upgrading the service now platform or upgrading of scoped applications or Store applications and so on that could all be tracked with the digital product another question from Anonymous is uh does this address release notes is there a process for release notes uh to be consumed by end users so you can um you can have a like a task in the background that would generate the release notes right so have uh have your your tasks laid out one of the tasks could be generate the release notes but it's not specifically within the scope of the digital product release to create the release notes but it's something it's it's it's definitely one of the line items we could track to make sure it gets done okay so this this um this build is just about complete and now when it's complete I'm going to show you that uh as we get a new artifact generated um we we'll be able to uh track that and track the uh version of it see we might have a pending version for that yeah 123 shows up his pending right here we're just waiting for it to complete the uh the the pipeline and then it will show up as one of my artifact versions here it should be the latest one at the top okay um and once it shows up then have the ability to then track the actual compliance of it under policies okay so we are you know we're linking the uh policies to the actual activities that are taking place in the pipeline uh we're looking for vulnerabilities from from security scans we're looking for code coverage we're looking for uh making sure all the stories are complete and in this case it would be complete in jira right all of that would make its policy and that would mean we completed this phase and the user acceptance testing phase uh we would make sure that uh you know all the user tests passed in many cases these are done manually right so we don't have to rely on data just in the service now platform let's say they're checking off uh that that things were approved in another system we the policies could actually externalize you know those queries and and and bring that uh compliance or non-compliance into service now okay so okay this should be complete if we go back to our artifacts here we should see we now have a um a new artifact Let me refresh this number 123 there we go okay so 123 now now if I want to see okay what happened in in this autofact if we scroll down we can see there was actually a a failed uh test here one of the test results failed that should now be reflected in my uh policies okay so what I'm going to do I'm going to show the policies I'm going to read run the policies now policies will typically run once a day you could run them more frequently it's a it's a batch job underneath that runs all the policies against your release and uh but you could also run it manually right from here and if it's uh and if you want to check the policies if you refresh this now it shows as non-compliant because that particular build 123 uh is um you know has failed now it it's it's not that the bill failed but it showed that one of the tests failed so now that's why it's non-compliant okay okay now the next thing I wanted to show you and this will be the last thing is the uh integration with the uh change management right so if we go back to uh that particular release um I mentioned that as things are being deployed we are creating uh change records and as you can see we've already deployed several uh versions of this application of this particular release to production even though not all of the features were met we this is called continuous deployment when when when uh pipelines are actually deploying small changes incrementally to production we still need to capture change records and we could do that in a manual way I can create a change manually and and simply uh link it to the um link it to the release or I could run a pipeline a deployment Pipeline and then uh you know using our devops change velocity ution it will automatically create the change so I'm going to go ahead and kick that off uh and what's called this 0.9 well 122 wasn't a good build hold on 0.9.1 12 two is the one I want right we're GNA ahead and run that uh that wasn't a good build so we'll go ahead and deploy that and then we'll get a new change uh for oh it looks like I hit it twice okay that's fine we'll get a new change we'll get two new changes now uh for the for these deployments that are going you know before they go to production and deploy we'll get a change record for that okay the other thing I could do is I could create a new change right from here I say hey let's create a new change uh let's create a uh a devops change I could even um link uh devops data to it right I'm sure you've seen that but uh we can go in here and say okay this is the uh fmr application and and this would just say manual release of manual change for deployment we'll go ahead and save that and then that change will also show up as linked to the release process right here okay so you'll get automated changes you'll get manual changes and uh you know basically depending on how mature your implementation is uh will will deter what type of uh task or policy you use or what type of automated change you use you can start out doing everything manual and then slowly migrate task by task to policies for example you could start out with manual changes and then once you become more mature you could you could uh Implement automated changes using devop change policy okay so that's uh that's pretty much all I had kayin are there any more questions we can answer yeah I left I left a few that we can we can talk through um so if someone makes an update in service now to one of those uh feature items and moves it to lease that is not essentially they're asking if they make an update in DPR um for a feature will it get reflected in jira uh right now no the current behavior is really a one-way integration from jir to service now the only reason we allow folks to uh track features in service now is if they don't have that jir integration set up or if they don't have the S you know SPM solution set up or Azure boards if they want they can manage features in the digital product release product because it's an important it's an important capability we provide it but the goal is if you're using jir then you stick with jir to to do those mappings and and it's a one-way integration it won't it won't change it in in jir uh one other question is about uh seeing the release calendar view could you yes the release calendar so that is uh let me go back to um back to Andrew so the release calendar right now is uh is about tracking um release ready dates and Readiness Target dates for various uh releases so uh let's see here so this doesn't have let me go let me see if I have it let me go back to she should have her releases on her calendar no she doesn't have it ready to tet right here okay there we go yeah these are the dates that we expect the releases to be ready by obviously there's going to be more coming in the calendar so you'll be able to see um basically the durations of releases and the and the uh uh you know more details about what's happening from month to month with the various races we're we're also planning on this calendar view to bring in blackout and maintenance windows and holidays that's on our road map for an upcoming release yeah but not not available at ga uh all right another question what is best practice to incorporate security patching to existing applications uh systems into release management yeah so p ing an application is another release process right it's another type of it's probably a different template with a with um because question not uh introducing new features you're just fixing bugs the the testing is going to be different you're going to have uh you know maybe like a minor release template with fewer phases and fewer tasks involved but it's uh there's no reason why you couldn't use um release management for for tracking the patches and and small incremental releases uh could you show and talk about the relationship between digital product record uh table I'm assuming and this release workflow functionality okay digital the digital product record um is the record of the product and the question is to show the um relationship between the the product record and well a product can have versions and then versions can have releases um that's the relationship that I'm aware of is uh I don't know if there's somebody else on the call that can give a more detailed answer I think this is probably one that would be good to have Colin respond to so Jay what we'll do is I I'll save this question for Colin it can give you the the Deep intricacies about how how the tables are connected in works and I'll we'll share that with you after um one other question from Jack is what if I create a hardware release template so at ga uh digital product release uh the name kind of says it but it's it's meant to focus on software product releases so we don't support uh Hardware product releases you could theoretically I guess create a template and make it fit for a hardware release but uh the experience that we've designed uh has been centered around software product releases yeah really the labeling of the fields and things just wouldn't match up today for for Hardware I mean if you wanted to you can change the labeling but it's uh it's customization that we wouldn't encourage I think uh Jeremiah are release phases visible on user stories and epics out of the box not sure I'm clear what this means or release phases visible oh uh so the user stories and epics i i i i if you're looking at it in um in Jer for example no you wouldn't see if you're looking at the user stories and epics you wouldn't see that I think that's the type of enhancement we would do for SPM right when we when we work on we have some plans for a Better Together story with DPR and SPM and understanding when you have a workout item in SPM what phase of a release it's part of or where it is in the release process you would you would definitely want to have that information on the work item we don't we don't provide integration back into jir today it's a one-way integration right now so you would have to go into service now to see where that work item is good question yeah I can see that being useful uh one asked are there kpi uh or dashboards out of the box for DP PR to to see how you're doing for a release process so um I believe that's coming in the May release a more I think so yeah a richer set of data propagated up to the dashboard to show uh release uh you know deployment frequencies and those kind of those kind of things yeah I know we're also planning to uh surface devops insights in DPR that's probably a little bit further out than the the quality dashboard that's coming out in May but that's another dashboard that we're bringing to DPR that exists in devop change velocity yeah I mean a lot of that data exist on the devop change and if if you have it you know if you have the data in the platform um we we also have proed it in some other tools yeah right all right um for release blackout periods will uh those will be shared with the existing feature with the change mod I'm thinking it's asking for blackouts that'll be surfacing the release calendar is that similar to what we use for change uh the answer to that is I I believe so um we're investigating currently how to how to pull those things in but I would assume what we've done for a lot of the other features is is work off um a lot of the capabilities that other uh products within itm use and I would assume we would use what change uses for blackout periods um will it detect any scheduling conflicts at GA no uh we're well there's some logic in there to prevent you I think from scheduling the same release on the same day potentially uh but at this point I don't think like scheduling conflicts in terms of blackout windows mainten windows and things like that not yet that's something that yeah the only place that capability would exist is in the uh is in that change record right because the change has a conflict calendar and if you had two changes deploying at the same time that would show as a conflict if if it's two changes for the same like application service or CI that that would show is a uh conflict okay is there a see there's a question about itm Pro um yeah so this is part of the itm pro license if you're entitled to it if if you have the itm pro entitlement you're entitled to digital product release thank you another question I suppose the product can be mapped to a CI as in release management am I right yes yes you can map uh products to uh CI uh the idea is that you you'll also map the um the release reles to software models right so there's there's really two links to the cmbb that way one question from Jonah is is there a Gant chart view available for releases uh I don't believe so yet uh but as yeah that's something that I think we are looking to into as we begin to uh look to manage uh dependent um releases and and hierarchal releases that's coming in future releases or like a future release for this product okay so any solution for providing a way to handle phased Hardware rollouts across thousands of locations possibly through a different product okay um yeah so these you know what you saw here were phases that included tasks and policies if you had the data of the you know the the status of those thousands of locations somewhere else then they could roll up to a policy I suppose but you know that would be um that would be some work on the other end to make sure that data is available and that's how we do there's nothing under there's nothing that I'm aware of in service now can track um Hardware routs uh at that scale right what else do we have Ken any more questions I see actually quite a few still coming in yeah uh one from a tool how can we create a new product uh in the cmdb or do we have uh some option in DPR how we do it in DPR is you can request creating a new product I think Joe might have showed that experience it leverages a service catalog flow that you modified to request a new product um and then that would be um put into your cmdb if if approved but by default out the box it's an auto approv flow and this I don't have a description so this would be just a creation of a new product this will actually create the um uh the prod up in the cmbb as well and uh basically what we're doing is we're requesting it and approving it through that catalog workflow you could add approval steps to that workflow if you don't want it to be that quick and easy to do you could make it so that there is some uh approvals in that workflow so that you know you're not it's not getting out of control with new products getting created can you explain the impact or benefit of cab meetings with regards to automated change request okay that's a that's really a devops change velocity question but the uh the idea is that if you are doing automated change requests and if you if you want to take a look at a a change velocity demonstration you can also do automated change approvals right so that's that's one of the features of change management is these change approval policies so if you're going to set up automated change and automated change approvals the idea is the cab is not approving the actual change however the cab is reviewing those change approval policies and that's what they focus on is to make sure that all the changes that are being automated into production are following a set of policies so you know all these changes are coming through quick and incrementally and and uh you're going to get a lot more changes with devops right so the change approval board has sort of a different role in that in that instead of approving individual changes just making sure the policies match the uh the governance requirements all right maybe uh one or two more I want to in our last five minutes make sure we get to our final poll questions uh before we wrap up okay yeah why don't we do that now because uh think we're just about out of time okay let me Ste the screen real quick any questions we didn't answer we we we should be able to capture who asked it and we could reply directly yeah we'll plan on getting those answers to you uh okay so final two polls um first is uh are you planning or were you planning use service now for release management uh yes you you do use or you've been looking to release man V2 uh yes after this presentation DPR seems like a suitable interesting solution uh or no we're going to continue using uh our current processes or undecided and then uh the second question is this open-ended are there any resources that would be helpful to you to take the next step in deploying DPR what those are and would just help us uh understand what we have if it meets your needs and we can help uh use that to prioritize so give this another maybe 20 seconds for you answer and then we'll go to our final poll okay actually can you launch two polls at once or do we have to close this one before the next one I think you have to close this one yeah okay we'll give another 10 seconds yeah okay and this one all right could you launch the last poll Greg uh and our final poll is kind of looking at Future sessions for DPR one um we're we're planning to have a launch and learn uh session which is like a deep dive learning series if you're interested in that uh please let us know um uh if you are interested we'll we'll ask you uh for your email and then uh topics for future sessions um we have a couple that we have in mind but love to hear from you uh Deep dive into Better Together use cases with DPR uh so things like modern change inform root cause analysis integrated risk uh maybe a foundational implementation Workshop where we walk through some of the um foundational use cases and how to get DPR set up uh and third I think always a popular session is a product road map session so looking at our next several releases what we have on our road map uh giving you insight into what we're planning and also getting your feedback on that so we can help make sure we're building the right things and other if you have any uh other thoughts please let us know I'm going leave that up that poll uh and go to our final slide which is a a call to action um so DPR is available as of Washington uh March 20th we went GA please start experimenting with DPR in your subron environments let us know what you think um second we we recently launched our digital product release community site we'll make sure to send that out to all of you after this you have the direct link to it uh but we have very some helpful info there uh so like getting started guides implementation and usage guides as well as uh FAQs that we've heard from some of the customers we' worked with over time they put into the fq please reference that see if it helps you get started with DPR answers your questions uh and if it doesn't don't be shy and engage with us on on community leave responses to those articles let us know what's missing what's still confusing uh or if you have any general questions on the forums we'll be monitoring that and and responding as quickly as we can but in general looking to get your feedback and get your hands-on experience with DPR uh and we're here to help okay well Greg do you do we want to end it here or do we want to um yeah looks like the poll has P has slowed down so I think I'm GNA go ahead end the poll and then we can end the session all right great well thank you everybody appreciate appreciate your time hope you have a great rest of your day or if it's the end of your day a great evening thank you thank you