but uh welcome everyone um welcome back to our launch and learn on digital product release this is our final session we're going to be covering um Advanced Automation and policy policy Administration my name is Greg hus and we have colban back today to uh present okay so Safe Harbor um you've all seen this slide so this presentation may contain some forward-looking statements um they're based on our beliefs at at the moment so please just don't take anything you you hear or see as Stone as it could change okay everybody um so you know again our vision for DPR you know we've done a lot through the maturity Journey where we've you know gotten started and we've been kind of creeping up the maturity curve to having more and more automation place because our goal is for us to automate as much of the process as we can uh especially around are we ready to release like that is our goal I would like for teams that are using this to only need to come into DPR when there's something that they you know need to accomplish like there's a policy that's not compliant um or there's a specific task but those tasks should be minimized to where especially approval tasks to be minimized so that we are really leveraging data in order to uh understand if we are ready to release so if we go back to the the adoption uh we started with just creating releases and having manual tasks in place uh we then went into how we can leverage Integrations to both help with planning as well as how we can use the larger cicd um tool Integrations to even create the change requests themselves and automate the authorization process by looking at the data within DPR to So within a release so this final is getting in to you know we have policies that that service now ships with but we need to leverage our own policies um not just minorly editing but starting from scratch um so for today I'm going to go through creating uh a custom policy so you can see how we do this uh so because we're in this webinar um if there are questions put it into the Q&A and we'll try and answer them as we go uh we should have plenty of time uh for today I've run through this a couple of times so um you know fingers crossed I don't have any issues as we go through it uh for today so one other uh just bit of information we have our content pack that we ship with a variety of common uh policies that we were getting from our customers I'd love to hear more about you know there additional things that would be helpful and the reason for that is we're we're not going to be able to get every policy into our content pack but if I see you know 60 70 80% of customers are like this would be like this is something we use or that we need that's how we determine what goes into our content pack is to help jump start you um and help with the common set of policies so that you don't have to uh so you don't have to manage them now for today I'm going to be going over again a custom policy I've got a little bit of setup I've got to review because this came from uh a request in our last session uh I will be doing a policy that looks at the test management uh specifically I chose test management V2 to look at data from test management V2 in order to Define one of our policies uh and the reason we got a review setup is because there is not currently an integration like an explicit integration between test management V2 and DPR so I added a field so that I could link the two uh and then I use that information in order to uh to create the policies um so once we review what I did because again it's very minor setup but I want to you know kind of set expectations um then we're going to go into defining a data collector now I I said last time this will be on the more technical side data collectors are done in JavaScript uh so I've already written the JavaScript I'm not going to write it from scratch um not even planning to go through it in uh in deep detail just some of the high level Concepts um because data collectors are a great way for you to separate out the where the data comes from from the policies which is more how the data is used and then I'll I'll actually you know execute it I'll show you what uh what goes on in order to get uh this data so data collectors again we've talked a lot about policies policies look at data within service now in order to determine whether you're compliant or non-compliant but sometimes that data is either not in a form that can be consumed or it's really complicated as to how to get to it so data collectors were designed so that you can separate out the data especially when you're trying to aggregate data from how that data is used because policies with the condition Builder approach uh doesn't require code it requires that you understand where information is coming from but you don't have to use code in order to define a policy but if the data is spread out or if it's difficult then data collectors are a great way to have a service now developer pull information together and then you can use it within your policies you can reuse it across multiple policies um so that's it's new so with the August release that came out last Thursday uh data collectors were opened up for um for anybody well anybody with the right roles to create prior to August so if you have it in subr and you're looking at our May release or even our initial February release and you try to create a data collector you can't create one uh you can create them starting in August so I'm on the August release now um and you can have a service now developer create these data collectors which you can then use when you're defining uh policies so before I switch over to my instance Greg are there any uh questions or chats that I should be aware of and answer before I switch over um let's see yeah we have one in the chat is there guy for the data collector do you need to know JavaScript yeah so there is a guey um but the guey is mostly for um the goo is mostly for like I have a place to put the code in so it's uh um you'll be seeing it so you'll see it in just a little bit okay so let's uh let's go into DPR so and actually you know what let's all also just have test Management in the background um at least I thought I told you to go to the background but it looks like I didn't mind let me switch back okay so what I did one thing that I did before we we got things going because test management V2 does not integrate right now with release uh with DPR uh it's probably something that we'll need to build an integration for it's come up enough times that it it's uh it's a backlog item but what I did is I have this Parts Unlimited 1.0 and I added a relationship on uh on the release record to say what is the test plan that validates this release so for those of you all that are not familiar I'll bring up the test board um so we can we can go through it uh test management 2.0 and I chose 2.0 because I understand it um I was the PM for its initial uh design and so I remember the the relationships on it test management 2.0 was designed to be used to say hey what are the tests that we have so we have test plans so this is my August release test plan it has some test Cycles which are like phases for your testing and then there are test Suites uh test Suites um let me I'll drill into them um so my test Cycles then have test Suites test Suites are collections of test um of tests that you assign to someone who runs them now these have all passed I'm still going to run it a little bit later but this is basically what we'd be validating however in order to get to it you'll notice that I had to go from I have a test plan now I've got to go through all of the test Cycles in order to get to the test Suites that then have my tests so that was a bunch of hops in order to get to the data that I ultimately need and even once I get here these results are actually result records so it's not just a value it's pointing to yet another uh yet another record uh and while you'll see that I do have some aggregate data here so I could short circuit if all I care about is the percent passing which actually my policy is just looking at percent passing then I actually don't need a data collector because I can just look at this particular value but if I wanted additional information like for instance um if I wanted to also have a policy that said there should be at least one test per feature like that could be a policy we want to have a test per feature then I need actual numbers not just aggregate like not just percentages in order to get to that number uh so that's I I didn't actually build that policy but that is a way where we can use all this data in multiple ways not just for what's the percent passing but I I can have some additional checks to just say hey if if we don't have at least as many tests as we have features then something's off we're not testing everything and that could be a policy on using this this uh data collector in a variety of ways um so let me get back into uh DPR any so the only additional thing I did was I put a reference from the uh from the release to the test plan uh I decided not to do it at the individual um at the individual phases could have done that as well but I just figured uh a release as a test plan so that is the integration I did all right so with the setup done adding that one relationship let's get into the actual policies themselves so I've moved into policy Administration and I'm going to start off in data collectors now I have already created a data collector down here but I'm going to start from I'm going to start from scratch so that you see what was involved uh again scratch does not mean though that I'm going to code this from uh from the start I have it in my on a on a text editor and another screen so let's create a new one so this is going to be tm2 test results that's the name of it categor is optional but I'll say this is being used for digital product release and you'd maybe want to give it a a description um you know results from my test plans and I have now a new data collector data collectors just like policies are versioned so by default I am in a draft of the first version that I would need to go in and now Define so I'm going to go into this draft and start defining things now the build side this is where to answer the question is there UI there is uh the UI is mostly me coding on this side and then me defining the inputs and the outputs for this particular uh data collector so for the data collector if you look through our data collectors most of them have a single input that input is going to be the uh release phase that we're looking at because again each um the label is um because the the policies are at a phase level so you need to Define it for the phase and what we are going to pass in is the CIS ID of that release phase that's how we use it uh there's no default value here and this should just be you know CIS ID of the release phase it's probably kind of self-evident but you know we've got a description and it is mandatory we cannot use this uh this um data collector if we don't provide this value so we have our input now we need to Define our outputs so outputs would be things like um passing tests so this would be the count of passing test it defaults to zero and it should be an a number should be an integer and we also want to know about our maybe failing tests and again integer and it will default to zero I'm not going to create as many as I actually put in my uh policy but I there should also be uh percent passing and again I use integers here um you could use floats but I use an integer so it's a it's going to be a whole number so it won't be like 57.3 it'll just say 57% um and then we'll also do percent failing and maybe the last one that we want are the total test cases because again this could be used in a variety of ways uh it you're not don't think of these data collectors as in it's used for a particular policy think about if I'm trying to get results of my test cases what results do I want like what are what's all the values that that we want to have so I could there's also blocking and uh and not run there's a variety of of more values I could have here and you should have them all in the data collector so the data collector can be reused in multiple places uh so now that I've got my inputs and outputs now it's time to start coding um but again I am not going to code this from scratch I'm going to paste in um and I'm going to go over a couple of segments of it so I'll do it from here because this is a little bit bigger screen so the first thing is is that this particular JavaScript it starts off with just the body missing but it takes inputs and it takes outputs the inputs they came from here so whatever the variable name is that is going to be a property of the input object that comes in so we have our input of release phase you'll see I even have it here inputs. relase phase I use that in order to get to the actual phase record and then we have outputs now I zeroed all of the outputs um it's just a thing I do it's not I don't think I've seen any of our developers do it so it's not necessarily required but I just liked making sure that all of my outputs were defined ahead of time uh because if I come across any any issues like if I don't have any test Cycles I exit immediately and I've got values in place by exiting uh immediately so again I Define mine up here but inputs are used I only had one input it's used to get the release phase then you'll notice in this code that I have a lot of okay I get the test cycles and then once I've got the test Cycles I get the execution Suites once I've got the execution Suites I have to get the test assignments once I have the test assignments I get the results and I Loop through all the results this code here you'll notice is what I'm trying to abstract away because if you're creating policies I maybe you're a JavaScript person uh but I don't expect you to be a JavaScript person I expect you to just want to use the results of it I then do a bunch of math um and ultimately I pass back into my my outputs all of the values that this calculated so I did some math because I've got my passing divided by total times 100 to get it into the range same thing here and I make sure it's an integer that then becomes my outputs so again I'm not focused on the the um I'm not focused on the JavaScript here just know that the JavaScript is meant to use Glide records you could technically make rest calls whatever you need in order to get to values that you then pass back that is the point of data collectors and then once you have those data collectors um I name everything the same passing tests failing tests I just don't have blocked and I don't have not run so I need to just remove them so no blocked and no not run uh but everything else uh think is is the same I'll probably use the other one I did for the end and then I activate this uh data collector data collectors again are the more complex side there is no condition builder for data collectors you are expected to be a JavaScript person you're expected to be a service now developer in order to interact with and build data collectors so if you are thinking you know through our implementation plan um where do I need a now development team especially if you're building new policies this is where you will need them the most so think about what information you need and then they'll figure out how do they get that information so that you can use it in your policies so before I move over into using this in a policy uh are there any Greg are there any chats or uh q&as that I should be aware of and then I'll move into using this in a policy nope nope nothing at the moment okay perfect so I now have a data collector now I want to use that in our policies so I'm going to go to policies and I'm going to create a new policy so it depending on um variety of things because Pace has different templates in place you might see a screen that has more options here uh I just start with a blank policy and we're going to give it a name this is going to be tm2 um 90 actually I'm going to do 50% tests passing the reason I'm going to do 50 is because I think that is how many are passing uh in my my uh demo when I was setting it up earlier 50 is kind of low I'm sure yours are 100 but I'm going to go ahead and create this new policy and you'll notice that it's a similar you know initial experience um but where it now starts to differ is in the policy Builder so the policy Builder is going to allow me to Define what my conditions are um you can switch to having a a high code version so if I do switch to code editor then you actually don't really have to have data collectors at that point because everything I just did when I used the data collector could be done in a high code version of your policy so you might have situations where your policy just requires code you can't do it with condition Builders then there is a high code like there's a a this is the no code side there is a a requires code side um but I'm going to stick with having um the the low code condition Builder we do have some things that again it's a little more on the technical side but doesn't require programming just requires Concepts be understood uh API variables don't really worry about that for today this is going to be information that we pass in to every single um uh policy that runs so I have pipelines and epic information and information about the artifact versions We go to configuration parameters this is where um you could when I said you know 50% Test passing I could have that here like I could say that you know I need to have some value and I I manually type in 50% but our recommendation is is that you have what are called config parameters this could be the Test passing uh threshold and it's going to be an integer because I've been dealing with integers and it's default value is 50 um and now I'm specifying that I've got a place to manage the fact that our threshold is 50 especially if we need to reference that 50 in multiple places here it's better to have it stored as configuration parameter that you'll use and if you need to duplicate this template maybe you've got a 50% template for internal but an 80% template for uh for or an 80% policy for you're more external then only having to change the configuration parameter makes it a whole lot easier uh to manage these policies and then we have I'm going to the record reference don't worry about that that's if I need to do a query for information a simple query to get it a table or record and then finally we have data collectors and I need to add the fact that I'm going to use a data collector and I have my tm2 test results and we'll just call this uh tm2 test results you can see a little bit of information so if you are uh building the policy you'll see that there are inputs now this input will be figured out um at runtime but you'll go in here and say I'm going to reference the document which is the release phase and I need to get the CIS ID that is going to be my input when using this data collector and the outputs well these are all the outputs so I'll know I can view them I don't do anything here I just view the fact that these are outputs but inputs you do have to say this is where the data is coming from with DPR again the document is the release phase it's always the release phase we pass in the release phase in order to um validate our policies and so I've got this here and I'm hitting save and I can now use this data collector so now the most technical side of the policy setup is done uh at this point we set our conditions so for instance I could have a condition that says if um uh if there are no no test results then we're going to fail things so for here um all let's say no test cases so technically if there're no test cases I might have 100% of them passing but if there are no test cases I'm going to look at the data collectors I'm going to look at the the test management to test results and I'm going to look at the total test cases and if it is zero why am I not able to hit is let's see less than or is zero okay for some reason my instances giving me an issue I can't tell in that field for some reason because again I'm in I'm doing a demo so of course I will have an issue well that's why I have a backup so instead of creating this one I will use the one that I had already built yesterday when I was setting everything up uh so you'll see that I had um you know no tests found I I was a little more tur in what uh what I typed in here but if I had no results found which the way I validate that is if my test plan total tests is zero then I specify that this is a non-compliant policy and I log a message you have to have tests on your test plan and I've got a failure message which would be in DPR like I can actually see this failure message that tells me that we had zero total test cases but if I do have like if it's not zero then the next thing we look at is the percent of Test passing greater than or equal to our passing threshold so again I have a configuration parameter called passing threshold in this one and so long as the value is above it then we say that this is a compliant um policy I don't really log anything but I do give a result that says what the actual percentages are then the last one is else basically if I don't have if it's if it's less than my my passing threshold I specify it's non-compliant I give a little bit of logging that tells me some information and I put a failure output that says what the percentage of test cases passing are so these are my conditions that I set up two of them are non-compliant one is compliant again there there could be more based on Nuance but this then allows me to have my policy defined and I didn't have to code I just had to have a a developer uh service now developer get the data for me which I could again use in a variety of policies that is the goal of these data sources um that didn't take me as long to fill out since I had to fall back to see why my instance won't let me type into it sometimes and and the last thing which you didn't get to see because I'm already I'm already here you do have to publish there's a a publish option um every time you make a change like if I needed to change what the output message is then um that will make a new version so I have an archived version I can see what the archived version looks like I'm currently on version 2.0 only one version can be active at any given time you can have a draft so if I were to create a copy then I'd be in draft 2.1 this draft is not used until I publish it so if I wanted to say no let's say for some reason um okay that um well I'm not gonna be saving this one but if I were to have updated this uh then um I need to publish a new version because I've made a change so the draft version is is draft it is not active it will not be used until I publish it but I'm not going to because I forgot that I can't enter numbers in here for some reason so that's creating a policy again the core thing is to know what data you want and how it's going to be used and at that point you will be able to create a policy but now how would it be used so let's go into my actual uh release so I'm in this uh Parts Unlimited 1.0 release and I have some policies now I added to the planning phase because I was in the planning phase I added my policy here which tells me that test management 2.0 uh right now is non-compliant because I have a threshold of 80% and currently it is at 57% because remember I have a failure message that comes out so we are um passing this is something started with August I am passing the info that came from the executions so people can see okay if it is a a non-compliant why is it uh and in that case I had no results but I did have a failure message that I outputed so if I go in now and DET test management 2.0 I need to impersonate uh Joe who has the the all right something has happened in my instance because Joe offenberg was my person who ran my tests let me reassign them real quickly so if I go into my tests and change this to I'll make Eileen the person who has to do it all okay so if I now impersonate ien then I can go into with test management 2.0 I can go to the tests assigned to me we have several tests assigned so I'm going to select them and run them give it a second test and now I'm going to go through in this case I'm gonna fail them I'm just going to say this is this one's failed this one's failed we'll say this one passed and this one passed all right so I have results some passed some failed so now that I've run these if I go back into DPR and I run them run the policies again it's going to look at that data we're going to run the policies again policy has been scheduled and now we wait for just a moment for the results to uh to come in and the message should uh should update unless something else broke while I slept last night oh no there we go so now uh we're down even further we're still non-compliant but you'll see that the failure message updated uh only 28% of our test cases are passing um because several of them haven't been run yet so my example policy looks at passing versus total some tests haven't been run so we're at a low percentage passing rate right now which means we're non- compliant which can be fine when we're early in the phase but toward the end of our phase we should be compliant and that would that would cause our risk score to go up because we have we're actually very far behind so this one's already uh readed on risk but I can't move forward because our test management 2.0 tests are not passing so since I couldn't do all of it from scratch I am ahead of time by about five a little more than 5 minutes um I wanted to leave 15 minutes at the end because since this is a more technical uh one I expect there to be a few more questions so um if there are now's a a good time to you know ask um you know to put things in chat or to put things in Q&A uh and I can answer on how you know any any questions about the policies data collectors of policy themselves and how they're used um now is a good time we just had one um where is the actual test data in PDF Excel Etc so in this case um the test data because it's in test management 2.0 is in those tables you could have like let's say you're doing testing with Excel for that I I don't I'd have to do some research into whether or not we can actually get into the Excel data itself you most likely want to capture it in in actual records but I have had customers that want to attach to the either the release or to the phase or even to a task um the uh the results of those tests so if you were doing testing in um in Excel what I know you can do you could do a policy that looked at attachments looked for the Existence of attachments on whichever record you use but I don't think we can actually get into the data um because it's Excel and I just don't recall I'd have to look to see if we have libraries that read Excel data from JavaScript now if you're using again um I use test management 2.0 so there are test management 2.0 records if you're using integration through our like cicd Integrations to pull test results that's being stored in the devops data model that's stored in our test results within devops um but in the case of if it's in Excel you can check for attachments but I don't think we can read the contents of them to to know whether or not you're at whatever threshold you could just say there are results that have been attached okay um so then what about links to the the data um so if uh so links it kind of depends um if you're storing let's say you're storing the data in um uh in um in what's called uh sorry you're storying the results like in a SharePoint site then again we can look at that there's a link but you'd have to do like a rest call in order to get uh information and so that we can only really see that there are links now if you're needing it for integration with like our integrated risk management so if you're doing policies and looking at um and looking at data um uh within irm then irm can actually look at the actual source of the data within service now to validate your policies and we do track let me see real quick um I were to go into the mapping of these policies um we do track you know execution information uh so if people are needing to you know dig in more as to what's going on what version was being used then more in is used including you know what values were being um looked at and what you know your config things are so there is more data being stored um but again that's uh that's if the data is in service now okay so then there was another question uh can you have multiple test plans per phase so uh in this case I can Ed DPR to test management 2.0 and I did it in a way that just said um here's my test plan for the release because I did it custom I certainly could have done something where I instead of linking it from from um the release to say here's my test plan I could have said here this test plan goes to this phase or goes to this release in which case yes you could but that's a custom integration custom really set up more of how the two talk to each other um it's fairly easy configuration to do within service now but you do have to create a relationship between the two so if you're doing it yourself then the answer is yes you could set things up so that each phase had multiple test plans um and you just have to you'd have to do that as a part of your implementation again we will probably be getting into a uh an outof box integration with test management 2.0 it's a win and I I do need to spend time on what should that look like within DPR versus what should that look like within test management 2.0 how do we bring them together uh that's come up enough times now where we're we're definitely investigating how it should work out of box okay um those are all the chats that I've uh that I've seen um if there aren't additional questions I can show at least I should be able to I need to to now I have to check whether or not my instance is going to behave but I can show a little bit of um of connections into irm that right now take a little bit of configuration but is something that will be out of box in a future release so we're we're going outside of what's in August and what is coming uh in the future so if if there are no more questions on policies I can talk a bit about how these policies can be connected with integrated risk management that's a part of GRC so you have to be licensed for uh for integrated risk management I don't know all the GRC SKS so don't know which ones give you access to what um but if there are no other questions that's one other thing I can go into before we wrap um uh wrap for the day all right I don't see any others so let me go into uh let me see if I actually even have this instance configured if I need to jump into another one yes this one is configured for uh for exceptions okay um so um again this this is something that it can be done in August but requires some configuration to set up we're going to include that configuration we're currently sizing whether we can get it into November um or if it will be in February most likely it'll be November but this is a capability that actually comes with the policy as code editor which is referred to as control Point exception it basically allows you to have controls mapped to these policies and pace and have an exception process for you know let's say that um that you can't meet this particular uh requirement and you need an exception an actual exception in place uh well in order to do that let me go into the compliance workspace talk through a little bit about the the fundamentals behind it so let's go into my control objectives and this one trying to find one that I've already set up so that it it doesn't take uh doesn't take time so if you are not familiar with irm uh integrated risk management has you know authoritative documents that have control objectives that then have controls in order to manage whether or not you are compliant with this uh this control objective so this is test all software changes before you implement them in prod you can add policies that come from within DPR in order to validate that we actually meet these objectives so I've mapped two policies here which are going to be enforcing this particular control objective oh was there a I see a chat um okay so and actually this is a this is not a good one this was one I did during testing see if I can find a uh we created some some test ones I'll just I should be able to do this live um I just need one that doesn't have any policies to show what happen so I can add policies to this control objective it will then look at which policies are identified for saying yes this uh this does meet whatever our requirements are and once I add them in the background um it is going to create a bunch of controls that validate across all of our releases now this can take some time so I may not have enough uh time to go into it in more depth but basically what happens is those for all of those policies it's going to look at your releases and those will be listed as controls that you're validating your compliance team will care a lot about that because again it it validates the data um inv validates that the policies are compliant and helps with audit uh now I'm not going to I'm not going to wait for the background task to finish once that is set up that unlocks the ability from within digital product release to ask for exceptions to a particular um control so my 80% Test passing I have a release that um that isn't able to meet it so for this particular release uh phase I have this policy that I've asked for an exception that will go through an exception process so if I were to and this one's already been validated but when you're using irm this will actually even put in place there are specific time period that you are even able to keep this compliance in place and what that does this one's already granted what that does is that when you have and I'm just going to go into a release you'll notice that I have these two compliant and non-compliant if you have an exception in place and the exception is within the time period again exceptions are only good for a certain amount of time maybe a month maybe six months that's your compliance team then there is another value that will show up here that says compliant with an exception or compliant with exceptions that means that this particular policy ran it technically failed so we still have the data about what happened but we will still be able to continue through this release or at least through this phase because we have that exception in place if the exception wasn't in place we wouldn't be able to continue but that will allow us to continue through the process on a policy by policy basis that is in compliance with your actual compliance team so again it's something that we we can set up today so if you are implementing DPR if you're using integrated risk management and you want to take advantage of this the feature is already done it's just there are a couple of Records that have to be created um to let irm know that you want this with DPR most likely in November those configuration records will just be in place but if you need help and you want to use this in the meantime reach out to us and we can help you with doing that setup it's uh we got a knowledge article on how to do it uh it doesn't require us to even like hop into your instance we can just provide what the what the actual steps are um for you to tell irm about DPR so with that we've got about well six minutes um because of the last session I just want to you know thank everyone if there any other question were there any other questions Greg um in the Q&A before I switch back over nope nothing's coming through okay well then go back to the PowerPoint real quick um so again I want to call out well first of all again thank you all for joining in these sessions um I I've enjoyed you know connecting hearing feedback and even getting examples for uh doing you know this session uh so thank you all for participating um definitely leverage our community sites so we're producing content we've got some videos that are that are being produced right now you'll recognize many of the voices because Greg's done some I'm doing some we've got Joe doing some bology who's on this call is doing one um and so we're all kind of pitching into creating videos to help people get started uh those will be there and we are also engaged uh answering questions so definitely leverage the community you have our contact information and I have several names from our last session on the rollout plans and we'll be kicking we'll be kicking that off in the next couple of weeks so you should be hearing more from us um but if there are no further questions um then again I just want to thank you all for joining and participating through these past uh seven uh seven sessions and if you have anything you can always Reach Out