good morning good afternoon good evening depending on where you're calling from this is now our eth digital portfolio management launch and learn today we'll be joined by Colin O'Brien he's going to be talking to us about digital product release and its relationship with DPM um this is our second to last session uh we sent a separate invite for the last session which is going to be a road map discussion if you not get that invitation or you missed it somehow please let me know happy to forward you the invite um and see you in a couple weeks but with that I will hand it off to Colin uh you should have the ability to share Colin let me know so let me share my screen get all the zoom stuff out of the way switch back over to PowerPoint okay is uh everybody able to see my screen yes looks good all right yes um so uh thanks everybody for joining uh as Chris said my name's Colin O'Brien I am on the product management team um working on reimplementing our support for the release management space um and digital product release is the current working name uh it is subject to change because it's has to go through naming committee and just final validations but it's what we're using um uh at this point and it's important to note this name and why we're calling it digital product release versus just simply release management uh which I'll get into in a little bit but because this is um uh Futures we're planning to release with Washington um but uh since it's being recorded the lawyers will make sure that I have showed this this is a forward looking vision statements so don't don't make buying decisions based off of this um a lot of things I'm going to be showing today are already implemented and we actually did a a hidden lab release um last Thursday um but again things are always having to change and just keep that in mind uh so this is my kind of General PowerPoint I'm gonna um uh walk through give a bit of background as to what we're trying to accomplish this time around with release management I'll go through U you know the kind of process that we're looking at and go through a demo so that you can understand you know what we're building how we're approaching release management this time around um so let's uh let's start with what our what our vision is um so we're really trying to focus on how we help to automate the release process uh so we're looking to be more of a process orchestrator we're not trying to be like a deployment orchestrator at least not um not at this point um that uh allows product teams to validate that their their releases are ready uh we're effectively trying to provide the benefits that you know the the release governance process provides but without the overhead that it typically incurs uh so that's why the process orchestration and also the connection with the rest of kind of the the service now um value stream is important so we are building in explicit connections to bridge the planning that's in uh the the SPM business unit with their strategic uh planning workspace um release will then pull in data from you know devops change and the devops Integrations and will explicitly link out into change management and into the broader itsm World while providing metrics that will be consumable um you know Caitlyn and I have been working on what what should that look like again we're we're bridging things we're using the concepts that already exist within the common Services uh data model so that we're not having to try to get you to use yet another U another record to relate to things like products and services um so let me skip a couple slides just to to kind of further emphasize that this is connected um so as I said earlier we're calling it digital product release because we're specifically focusing this user experience based on how we deliver digital products so software effectively because with release management while many of the concepts can apply to things like infrastructure releases or for like General Hardware releases the experience the kind of things that are important to those teams are different and this time around instead of providing kind of a general kind of framework which release V2 was more of a general framework that you could Implement your own experience on top of uh this time we're we're really focused on the experience of how we deliver um software so that's that's why digital product release and it starts if you are using SPM it's going to start on more of that intake what are the things that you want to work on you'd prioritize all of that in SPM and then release kind of links together to say okay we now know what we've prioritized we've kind of uh decided what we want to release now let's track that delivery so release management is really going to be focused on how we track the delivery to track the Readiness of the software that you're building and we'll be connecting in with uh the devops data model and with devops change so that as work is going on you've got stories in jira that you're wanting to um that you're wanting to capture you have test results coming out of your cicd pipeline or security scans coming out of your pipeline and you want to pull that information in in order to validate that we are ready before we raise or before we we um authorize the change request we want to move that earlier so that it becomes more of a uh datadriven uh approach and then again where we have some explicit connections between uh release and change that we are building in order to make the change process hopefully uh simpler because we found with a lot of customers we've been interviewing that the change management process is effectively become overloaded with a lot of release management Concepts so we hope to help your your change teams to have a a simpler more streamlined change process that connects with release so all of those activ activities can happen earlier instead of finding out that no we can't actually deploy because you missed something um you know a day before you're trying to deploy your software um so that that's the that's the vision for what we are building um so another thing that I just skip the the personas another thing that we're really tackled on is what does this process look like so what I'm going to be um what I'm going to be going through when I get into the demonstration is you know starting with what is the scope from the release now we are um uh we're working with the SPN team uh to have an explicit shared concept of what we call a product feature so this is what you want you know to be delivered what you want to be evaluated to say this could be something like uh we want to support single sign on it's not the how that you implement it's the what it is that you want so we Define our scope and we plan that scope into uh into versions and we're very explicitly now bringing the concept of Av version out into digital product release because Again release is about how we validate uh this new version getting out the door so you'll say here's what we want to be in this version that we will release um then we work on you know selecting the actual date for the release we can select the uh process that we want to follow for this particular release then we start executing we validate that the release is actually ready and that happens before deployment deployment is still within change management there is no plans to alter that in any way because change management is really that final authorization to say that um yes we've done everything necessary in order to deploy however change will have the ability to see into the release to say what were the activities that went on that as someone on the cab or if you're automating that process with uh with devops change you will be able to leverage this data on better evaluating did we do all of our activities um so Let's uh are there any and I'm not monitoring chat so um you know Chris or Caitlyn if some question comes up in chat just let me know otherwise I'll I'll continue we'll do we're good for now perfect uh so that's kind of the general process but before I switch into the demonstration to kind of show you how that works uh I want to break down these to really kind of talk about what it is that we're doing so we start with that notion of planning a version we've split out the notion of a version from a release a release delivers a version so this gives you the ability longterm to be able to um associate like your application services to say this is the version that's actually running on this application service by splitting out these Concepts so a version has what you know features what what things this version is going to uh is going to have um and you will plan that from more of a backlog into the versions themselves those features those product features we're calling them then break down into the work items this is the tie-in with the devops data model to be able to say that this particular feature is implemented by these work items this will give you the ability to have have policies that we'll talk about in a moment that can look and say have we completed all of the work items the stories the epics um that that have they all been approved have they all been signed off on by the product owner uh those work items through how the devops data model Works will be able to connect to the code itself so if you're needing to do an audit what were the things that actually changed then we will have a link to the code itself that says here's we actually implemented or if you're doing root cause analysis and you're trying to understand with problem management um you know what what you know change where do the developers need to go and look we'll have that traceability um we'll also be tied to the builds themselves so your cicd pipeline is producing um it's producing builds it's producing artifacts we'll have a link there so that we can also talk about what all the test cases are so we're creating a complete traceability to say here's what your teams planned to deliver did they Implement them what implemented them how are they tested how are they validated and be able to have that complete chain of custody from plan to the actual implementation so once you have defined what it is that you want to work on next is when you want to deliver it so I'll give the example like uh and I just I made up version numbers for our products um but but if you plan to deliver a new version like I'll use service now as an example we plan to deliver digital product release with Washington so our 1.0 our version 1.0 is like I have my scope of what's in 1.0 I plan to deliver it with Washington Washington's a nice name around a date February is I believe the um the go live like first week in February uh would be the go live for this product because we're using the store in order to deliver this so I've got my version I have when and that also then gives me the process for what are all the activities that I need to accomplish to ensure that I'm on track and that I am ultimately ready to release when the you know uh Washington time frame actually actually hits uh so this is we're separating out that what from when and release is ultimately validating that we are ready for that new version based on the timelines we need and then finally this is all underpinned by policies so these would be the requirements these are things like are all stories accepted um are test results above 85% uh do we have any uh critical security vulnerabilities and if we have have any then that's not allowed we have to have those fixed before we can release it can also be things uh some customers that I've worked with they've provided their um their uh policy documents to me so we can start putting together a library that customers can use when they they first install this but another one is are all of the versions of our components the same in our staging environment as they are in production now that data is just looking at the cmdb so instead of having a person you know manually go and check do I have the same version of each of the libraries that we care about are they the same in subr as they are in prod that's a policy that you would be able to represent in digital product release and if it's data that service now has and this data could originate from anywhere so long as we're able to collect it and store it in service now then you would be able to use it to automate the evaluation of that policy now they could just be what I'll call manual attestations you could have a task that says has the uh QE team signed off on it uh is uat finished those could just be approvals that someone has to go in and attest to but it's a whole lot better when we just say let's look at the test results are they above whatever our criteria is let's look at the scans from sonar Cube do we have any critical vulnerabilities uh let's look at the cmdb uh do we have you know proper service levels to find for the application service because maybe that's one of your policies if service now has the data then you will be able to use these policies to help keep you on track and these Poli policies are exit criteria to move from one phase of the release to the next so it's all underpin by these uh these policies That's How we'll able to provide the uh the benefits that governance the release governance uh provides but without the overhead that typically incurs by someone having to manually go and collect all of the evidence to ensure that yes we have done whatever it is that we as a company have said we need to do in order to say that we are ready for our release uh so that's the end of my uh slides I was going to switch over into um to one of my instances to show you how we're doing this um but are there are there any questions in chat at this point or any questions before I switch over we do have a couple questions from Mike saon um he asks what CI class are you targeting to release from a majority 8020 rule assuming app service is below services and offerings yeah so anything can be the target um a product which the ux that you'll be seeing in a moment uh I I try to avoid using CI terminology because most of the teams that I work with they don't know the difference between an application model and a software model and honestly I didn't either until I spent a lot of time with Mark bodman who who is one of our csdm Architects and Specialists um but like if you know application model and software model found like synonyms uh in English at least it's kind of like normal change and standard change normal and standard like mean the same thing in English but they have two very different meanings in the context of change management so an application model is basically your product doesn't have a version just the product software model is a version of that product so those are both models those models can be linked to whatever CI class that you will have for production I typically say application service because that's the recommendation of the csdm but really any CI class could have the model I believe it's model ID is the actual field um you could actually have any um you know Target of a change request say that this is now the software model that is associated with a service an application service it could just be an application whatever you tend to use um they all technically work um but I am leaning into more about the App application service because that's the recommendation of where applications uh deploy to but there's nothing in our architecture enforcing it yep I'd like to just make sure that there's Clarity there I mean I don't want to be rich or anything like that but you know as as companies you know mature and they you know this this audience here is very familiar with the csdm model so we're yeah you know we see the business application at the top in the design phase as it drops down into the operational piece of it um down into the the orange where we have application services and their Associated offerings to the technical and business services um yeah we we we see that as a as okay then let's fit that into the whole if you're trying to figure out a life cycle of a digital digital thing um then you'd want to be able to follow what we see in csdm 4 right now so when you as soon as you jump out of that um for me it it kind of blows me blows me out a little bit right so that's why Focus that yeah yeah we're following the csdm 4 recommendations and I'm working with um with Scott and Mark on the data Foundation side on the proposal for cstm 5 uh because it'll be incorporating some of the concepts that I'm building now um so application model is the kind of top thing application model then connects to the business application so there's a um a link between those and in fact I believe they are releasing with Vancouver um I think it's starts deactivated but it's recommended that will keep your business applications in sync with application models so that you'll have that thenit application model also has the sdlc component which that's the devop side so an application model will have that link to the stlc component which has the work items and the code commits and the the pipeline runs and all of that um and then it will have the software model to represent the versions of it and digital product release is trying to hide that complexity we're simply showing you the pieces knowing that that's how they're supposed to work everything up until deploy when you get to deploy and you have whatever your CI is that you want to Target for a change request that's where we recommend things like application service and the other recommendations of csdm 4 but um we're not enforcing it at this point to where it must be like an application service okay thanks yeah no worries any other questions before I switch over to um to the demo I saw there were some I saw a number next to chat so see there any other question we have one fairly long L I don't know if you want to come off mute and uh ask her a question thanks yeah appreciate it yeah so the application model as you indic is there it's tied to the business portfolio VI the model ID the software models also have a product they're based on a product both have life cycle phases if you're if you're opting into the Content Library system service now provides the life cycle information if they can get it from you know the public domain which is not always available and it's big Garg win you know Endeavor to maintain all of that so the question really is I don't think there's any expectation to maintain the life cycle information at the application model so in release management that you're talking about you're talking about the version well if you have an application model you I believe have to add oh this is you know version 1.0 version 2.0 by adding a general availability date to the life cycle phase of that application model I just didn't never saw because we op in into the Content Library that service now provides that for application models but certainly they do for software models so am I missing something here how that's going to relate to your new uh release management implantation come Washington no so we are um right now we're minimally interacting with the life cycle status uh the life cycle State um of the software model it's actually one of the areas we are investigating at the moment how we could automate especially for custom so when it comes from the Content Library that's generally like let's say you are using release management to manage your service now release um in that case the life cycle is pulling in from what's the state of the the cot software versus if it's custom like it's inhouse then the life cycle status is really based on you uh setting the life cycle status we already have implemented some of the things to like say that the release is in the build life cycle status as an example when it gets when it starts basically um we're still investigating how much more we should lean into the life cycle States because we're doing it minimally at the moment so if it's something that you are interested in it's something you have an opinion with I am happy for you to reach out uh to me and we can set some time up uh because the only reason we haven't dug in anymore is because I don't have any requests at this point uh none of the customers I have in my design partner program have an opinion on how that should work so we're trying to stay minimal at the moment pretty good idea have be happy to reach out to you I would just make be clear make the distinction between life cycle stage and life cycle stage status on the model which basically means that hey this stuff's no longer valid we're going to retire it or it's going to be or whatever that's different than the life cycle phases which are relative to the versions so yeah the combination of those two working together in conjunction with how you're going to model this new product is uh I think is an important Point look forward to talking about in the future thank you yeah no worries and um I now I don't remember if I've got my name explicitly on this but I should be on the invite but it's just colin. obrien at servicenow.com uh so feel free to email and we can set up some time thank [Music] you right any any other um uh last questions before I kind of show um show some of what we've built so far knowing that we're still months away from uh from GA nothing in the chat but y'all feel free to come off mute if you do have a question you don't have to throw it in chat yeah and it it doesn't hurt my feelings if you interrupt me um so I I'll I'll make sure to watch the time um but I I don't I don't mind being interrupted okay so I switched over into one of my instances this is running the lab release so we again did a hidden lab release last Thursday if it's something that you want to evaluate in subr send me an email and I'll send you the instructions on how to get it um because we're I'm basically wanting anybody who installs this I'm wanting to get your feedback on uh on what you think about it because that's going to help influence our last half push to uh to GA um but uh we do have basically a working version at this point so it starts off with what we have is policies so if you have seen anything with devops config then you will be aware uh of the policy system this is leveraging what's know as the policy is code engine and it looks like of course my instance is deciding to be slow at the moment U but the policy is code engine is basically a way for you to Define what your policies are and have them evaluated using originally code now it's a little bit of a misnomer because you can do the policy code engine um and there we go I guess it timed me out at first uh so you can uh you can do it with a condition builder in order to specify what your policies are but I have a policy that says all release tasks are closed and I'm not going to build them out just in the interest of time but you can basically say I want to look up all releases I'm sorry all the tasks in the current phase that um and you know get a count of how many are closed or how many are not closed because then not closed means if it's unless it's zero um then we're not compliant with this policy but you can have as many policies as you like we will be and think of this as a library these are reusable across your releases um we're going to be shipping with a Content pack that has the most common policies that customers have provided as feedback things like you know tasks being closed approvals all being completed uh we'll also have things around stories and around test cases and security scans uh and several others based on again the common feedback but if you needed to have more than a release um like a release manager release admin someone who owns the policy side of release would be able to Define new policies and maintain them within this list of reusable policies across your different kinds of releases because these policies are then leveraged with our release templates so release templates are um we got a a question in chat here Mike asks interested to see where this shows up in DPM or the plan to Bubble it up there it so um the I will say that the status of these policies are will bubble up into the phases of our release so we'll know whether or not the phases themselves are um are uh you know compliant non-compliant or really what's the risk status because all the policies being non-compliant at the beginning of a phase kind of normal um but as you get closer to the end of a phase the risk starts to creep up so risk and Status were what we're really thinking about exposing not the details of the individual policies however if the details of individual policies would be uh useful again that's an area where uh we're working on designing what provides value do you need the the details or just the aggregate based on um uh based on what's happening in the details yeah thanks no I was just it's more of a comment to hopefully we have enough time uh since this is a a DPM launch and learn that it's you know we see where this this plays into DPM the the overall the overall product of this release why we care you know why we should care about it from a DPM perspective yeah and I can I can jump in real quick so just adding to to what Colin shared we have been um Colin and I have been connecting on on how his product is shaping up and where those linkages really make sense and a lot of the decisions that we like to make when it comes to DPM is really based on uh you know your feedback as as users and customers and what data will make sense to surface in DPM and how to surface that and so the idea today is to share you know what's coming and also to gather interest uh in participating or in Sharing expectations that will help us um you know prioritize how we surface this data into DPM um so you know feel free to add in the chat or you can message me directly if you want to have a conversation uh so everything that call is sharing I think will be you know really good context for what the product is going to shape up to be and then how we can you know bring those linkages into the DPM workspace got it so it's an awareness of of potential inputs from this product but it's not it's not there yet that's just um it's just bringing awareness of what could be absolutely yeah because like Colin said this is kind of early stages it's not you know GA yet the uh and so and he's still working on refining and and fully building out all the the key features um and so what we would do is is you know we would align once he's getting there and again in terms of what will make sense um you know based on your feedback so got it okay thanks yeah yeah so um so these and and and because of this I'm I'm not spending a lot of time on how setup works because that's th this provides context uh I'm going to spend more of my time on more the the product and release side in just a moment but policies then can go into the templates themselves which templates are uh this is actually based on some very common requests I got from customers on release fee to you can have multiple templates these let you know what are the various phases that um that you know commonly exist for a kind of release uh as well as if I go into to manage real quickly so I can I can click through a couple of areas uh allows us to see the process um so there we go uh so for the phases themselves um this would be again uh what are the the the phases of the release there we go uh so in this case I have like scoping is 10 days uh like that's when we can you know continue to put things into the release development goes on for 30 days uat is 10 days and I gave deployment a couple of days window um so these are these are the phases that we'd be tracking and those phases can then have tasks which tasks I don't think I added any yeah I didn't um with this one but I can have tasks which maybe are just activities themselves or they could be tasks that need an explicit approval so someone attesting to the fact that thing happened like you know QE sign off or uat was complete or scoping was complete um those are the fallback for when you don't have data that we can use for policies to say that certain activities uh have to have been finished and policies can be leveraged across multiple um uh across multiple uh phases so I can have the same policy that has to be evaluated once during scoping again during deployment or development uh development I could have this is where normally like stories would come in uh uat might have testing deploy might look at things like are the change requests all closed um and closed in a complete uh State um you could have maybe post- relase here but this allows us to reuse a common set of uh activities that you need in order to ensure that you are ready for the release um instead of having to Define it each time and then last last ly we have the dates that we would be targeting so the uh the calendar is managed by the central release team on when is it that we can uh do a release um so I think I I created one the other day here yeah in um in October so I had one at the end of October uh I only have one release right now targeting this particular um uh this particular date but I would be able to see releases I'd also be able to see changes so we'll have a date concept where I can just say what are all of the releases that are planned for a specific day what are all the change requests for those releases will'll also be able to roll up so those are the the kind of fundamentals that the release team defines the policies templates and the dates themselves and then on the other side this is where we have the product piece to it so again I'm using the term products here uh I'm not calling it application model because while um you know for those of us on this call we understand what that means most of the people in the release world don't know what an application model is they don't know what a software model is so I would be able to have what all of my my products are and this would be either application models also business applications so we're going to uh ensure that it all shows up here so if you're thinking to like your um your either personal portfolios uh where you have a collection of business applications that you were wanting to manage then those would be linked here as well we're using the exact same uh exact same Concepts now I don't yet have the hierarchy built in like you have with personal portfolios and DPM that is a piece that's on my RO map um So eventually I will be consuming the portfolio Concepts um that way you'll be able to organize these instead of just seeing the list of either everything or the list of just what are your uh your products but that's future state for me um but the fact that we're leveraging the exact same entity means that that there's not going to be some additional connection that you will have to make within um your Port personal portfolios they'll just once we have the right metrics the right things that you want to see they'll start just showing up instead of you having to do additional wiring to make sure that we are in fact uh connecting the two and then as I drill oh go ahead yep yeah so is there a dependency on the uh on using PPM and with this because I saw the phases there and you know with the the Agile development out of the box capabilities a product Associates to a release and a release will associate to a project a project would then associate to a phasee on the other side the release Associates to a group and then to a Sprint because if you're not using PPM right so you can use agile both ways so is there a dependency that you have to have a project and then the phase with this release management nope it's the same terminology but different uh different concepts uh so and even the Agile Release this is so my background um I've been in the agile world for the vast majority of my career when I came to service now it was a for a quote unquote break from that uh portion and that break happened for about a year before I became the owner of our releas our at first agile products um and then devops and now I've got a release that I'm trying to shore up the Agile Release was actually not meant to be used in more of a release management function that's kind of an artifact of scrum being poor at naming some things uh safe doesn't do any better but the Agile Release was actually the precursor if you follow safe to a a planning increment which is it's meant to be something that like if a Sprint is two weeks an Agile Release is maybe four Sprints or five Sprints um and it's supposed to always be that number of Sprints you may or may not deploy at the end of it you may deploy in the middle of it uh it was meant for planning purposes not for validating that a product is ready but there are relationships that are there um that they they do exist um so that you can kind of line some of them up but RM release which was what was meant to be for release management is different from a scrum release which is meant more for planning so um that that's a thing that we're also kind of fixing and clarifying uh so so to take a short question and answer in a very long way there is no dependency these are different concepts you could still use an natural release but it's meant to be used for longer term story planning and not validating that a new version of a product is ready they they have two different things but unfortunately share the same name that was an awesome answer I appreciate that thank you and here's the thing uh the reason I could answer it like that is because I have literally been answering it for nearly 20 years now so it's uh it is prevalent it's everywhere it's actually why the scal agile framework which I was involved with them pretty early on doesn't call it a release anymore they call it a planning increment uh it used to be a program increment they've just renamed it to planning increment uh because of that confusion right on appreciate it yeah no worries uh but the the concept of a a Project's phase and the concept of a release phase are similar release Management in that respect is almost like a simplified version of project management uh but it's something where it's meant for validating things instead of necessarily doing something the doing in release is only meant to be there in support of validation uh whereas project management it's about how you implement something but similar similar Concepts and therefore similar names so um uh just to real quickly drill in so again this this product itself has features features is a New Concept um SPM is adopting it it will be more explicitly in csdm 5 um and therefore won't really require licenses it'll be it'll be in lots of places but features are again what it is that you want the epics and stories that could come from jira or from Azure devops or from Rally or any other agile planning tool those are the how we validate that it actually happened um so this is your this effectively becomes your scope of the release and the epics and stories um are how it gets implemented and should take place either in agile 2.0 again my first product here so it's my baby I want everyone using agile 2.0 that being said if you're using jir and Ado it'll it'll function the exact same way you just want to have those have those connected um and then from there you would be able to do release planning to say you know given I have my features uh which versions do I want to tag it and again versions are software models so uh it is actually one of the places where if I I were to to edit this version uh I can't completely get rid of the termless it it does show up here it is a software model um we are exposing things like the the life cycle stage and Status um as well as the other status here this is an area where we don't really have a lot of feedback on how customers would actually want to use it now that we're going to provide an explicit way of validating them with release management so if this is an area where you you are using it or you have some thoughts about it please reach out it's a discussion we're having internally uh that I don't have a lot of customer evidence on how customers would use it um but we we do have this version here if you are using software Asset Management there will be a lot more on this page um we still we are working with software Asset Management uh in order to help with people that are doing releases of uh offthe shelf software um but that that's why we're explicitly using this as the the version itself and so you would be able to plan what features go in which versions once you know that it's set you would be able to don't know why my menu went away but you know beta software that happens you'll be able to create a version or create a release and that is where I am actually going to jump to because I I'm already in a release here this is my October release it is for the product of attendance and payroll uh it is the version 1.0 so a release always is producing is validating a version of a product that is that is intentional and then we are able to track for this particular uh release execution what the phases are that we're in we'll be able to see uh information about it we'll be able to you know track the various tasks which which um again I don't think I I have any and my add task button actually doesn't do anything at the moment so I can't add a task here um and where I'd be able to see for my policies as they run you'll be able to to track the status of them this would effectively update the uh status of the release um we have both state and status status is things like red Amber and uh green so you're traditional rag status um versus the state which a state of a release is like it's pending it's in progress It's completed um those are are I think there's one more state that we have for it uh so we are tracking both of them but the the the state of the policies would update the risk and status of the release itself of the the phase which would then roll up to the release itself and then we also have the connection to the features to say you know here is my feature um you know this is you know an epic for it this epic is planned does this epic have children it does so here are the stories some of the stories are work in progress I guess by jira doesn't update the parent when uh the children start going but you'd be able to track all of this information and you can't update it so very intentionally you cannot update the status of things like stories here you would need to go go into um go into jir I've got a link uh over here that would then navigate me out to my jur instance to make any updates because this is leveraging the devop data model uh you won't have to implement devops change in order to leverage um digital product release but you would be able to connect to your tools so that we can get the data from them in order to uh you know provide uh information that's uh that's important for your teams now what's missing because we have a bunch more tabs that the development team is actively working on here some more uh navigation elements the core things that we are actively working on right now are bringing over the testing information that would come from your pipelines so we' be able to roll up the the test results to the release itself we are connecting with um uh change management so we've added a field if you're using digital product release we've added a field to the change request that references the software model that this release you know is validating that way the change record itself instead of only having what is changing so which application service is changing I'm going to say that generically could be a different CI type uh CI class but let's say it's an application service that you've raised your change request for um instead of just knowing that the you know like our prod instance is getting changed the software model reference will allow you to know what about it is changing so we're we're planning to deploy a new version of our product to this application service so there is now an explicit link between them so your change team will know what is changing that way they'll be able to see into what's going on in this release are all the the policies passing like are they all compliant um have we done everything that's necessary do we need to see into stories and into test results we'll have that direct linkage and one of the proposals that we are making this will probably be off by default but um but something we're going to Shi with is once that change closes we would update the model ID field on that CI to reference the software model that way you will have better like traceability as to what is actually running on that service or whether on the application service or whatever um you know CI class that you uh that you use uh and you'll also be able to see that change over time so you'll know as you have new versions on the application service we'll work on keeping that up to dat for you instead of someone having to manually keep the app service up to date with the model that's um the software model that represents what's actually running on it uh and that should also be an area where we could provide some additional information on the the DPM side because if your application services that you're managing you'll know what is running on them um we can start doing some interesting additional correlations on you know when was maybe a defect found you know was a problem uh raised that uh was introduced in a certain version but when was it resolved um there's also some some discussions I'm having with the SE Ops Team about being able to link vulnerabilities and say that this vulnerability affects these versions which could be deployed to more than one app service um you could have different app Services running different versions especially if you have some sort of like a ASP model or SAS model for some of your products where you can actually track what's running where um and just have a better idea of it through that explicit connection between change and release that is in active development uh right now so I can't uh I don't have a good instance I checked earlier today the the teams nightly instance wasn't um functioning properly uh so I can't demo the chain uh change portion but that is being worked on right now so we've got about five five minutes left um I like to hold a little bit of time at the end for any additional questions that may have uh come up um or you know I won't tell your boss if you leave early and want to take five to do something else either way it's fine with me any questions for Colin Qui a bunch today right well then last I'll just uh just so it's easier to uh to get it since I did forget to put my explicit uh email in here so my name down here at the bottom there is no apostrophe in the email address sometimes I have worked places where they did put the apostrophe in my email address that caused issues uh thankfully service now it doesn't so colin. obrien servicenow.com if you have additional things that you'd like to talk with me about release management uh if you think that your company would be a good candidate for trying out the lab release and you'd like to get a link to it so you could install it in subpro um then you know feel free to reach out to me and we'll get you set up awesome well thank you Colin very much appreciate the uh great presentation today thank you everyone for attending um again we have one last session of this digital portfolio management launch and learn um it's a separate invite so if you do not receive that please let me know um as always I'll be sending a recap email along with all the recordings for not just this session but all of our previous sessions and a follow-up email you should receive that sometime Friday morning um the other thing there will be an exit survey in that email I might actually send that as a separate email please I implore that you fill out this launch and learn exit survey it really helps us to understand um how we can better manage these programs how we can make them better work for you and really get uh some benefit uh from both sides uh with that though thank you everyone for attending and you enjoy the rest of your week thank you