okay we're at one minute past the hour so I think I'm gonna go ahead and uh get started uh today we're talking about devops config my name is Joe Auffenberg I'm an outbound product manager in our devops business unit uh I've been with servicenow about three years I came over with the acquisition of a company called swiggle and what swiegel did was uh we had a config data management platform uh That Was Then acquired by servicenow and re-platformed into servicenow so when I say config data management I'll go through the uh the scope of it so you'll know exactly um what I'm talking about uh I'm gonna bring up uh another slide here so we can go through the scope of devops of config data okay so when we talk about config data uh we mean you know often it's data related to Applications uh that's becoming more complex such as microservices and and these are the config settings for how the microservices might connect to a database or might connect to another microservice often these include Secrets like API keys and passwords or things like feature toggles install paths database connections Heap size there's also release related config data so from One release to a next you might have different dependencies you might find these type of settings in an XML file like a palm.xml when you build your application you have certain settings there and then of course as you deploy and you run it through testing in different environments you're going to have different settings in different environments right so uh you'll have maybe a database connection string in your a test environment that's different than your staging environment and of course hopefully it's different than in your production environment right and then of course today with infrastructure as code you know folks using tools like terraform kubernetes cloud formation templates uh you know Google Cloud platform and all of the infrastructure is code has its own set of settings uh and and this is declarative config data so it it can be quite uh you know quite a volume of config settings and and that you know that'll make up the bulk of actually most of your config settings and it doesn't have to be infrastructures code it could be static infrastructure it could be resources that get provisioned in the cloud uh all of that is fair game for this uh devops config platform okay and what we do is we look at the data from different from different angles right so when you define that infrastructure and the cloud for example you might have different settings and and what you might call tokens or variables in those config files when you deploy it those those values are going to get filled in by environmental settings so the defined state is going to be different than the deployed state right of course after it's been running for a while you might have the uh discovered state right so you're going to go and see okay what are the settings now did they Drift from the original Baseline okay and then of course having the history of all those settings over time is is really is really useful so we want to be able to um you know make sure that that the the changes that have taken place one they're attached to a change record but also we can go back in time and see what were the changes two weeks ago what were the changes two months ago or six months ago so being able to take snapshots of those changes are really valuable so we have you know various states of config data but then for various reasons the the amount of config data is growing okay so some apps might only have you know tens of thousands of uh of what we call config data items or config date item is essentially just a key value pair one setting right it's it's uh the Java Heap size is this value right so that's a CDI other applications might have hundreds of thousands and then of course uh as the applications become more complex and they involve multiple environments with multiple uh application services and different ways of provisioning them in different geographies and so on you could have you know millions of config settings right so how do we keep track of it all and and um you know what what do we do for uh making sure that it's valid before we deploy it to uh production okay so uh so let me explain how we're going to do this and how it works so various uh sources of config data exist in your environment and this is one of the problems we're trying to solve because uh you know back about 10 12 years ago I was with uh the team of swiegel before swiegel was invented and we were doing release Automation and we'd go to a customer and we would say hey we've we need to help you know release your your deployments but we need to understand the config settings and often the config values were basically in in 10 or 15 different places for all the different components of an application some of them were in the file system some of them want a SharePoint or an Excel file some of them were in a database some of them you know and and more recently they we started seeing them in git repositories so we needed to to basically have a way to collect all this config data from all the various locations okay and then bring that into um bring that into a model that then we could use to track that config data right once we had it in the model we can start applying things like role-based Access Control do it uh we could start applying validation rules to it okay and continuously validate it as it was changing and that was extremely valuable and then of course having all of this config data in the model allowed us to then create some really nice uh basically some really nice exporters so we could generate config data basically generate config data from the model on the Fly and then of course uh having all of that data in the platform now in servicenow is going to allow us to apply some AI to it and some root cause analysis and also just assisting humans in predicting what kind of changes lead to bad outcomes for example right because um you you know as things start accumulating over time uh we can start tracking Hey whenever certain settings get uh deployed we see an increase in incidents we see uh an increase in outages or the monitoring tools start telling us that performance is starting to degrade right so having this data uh feedback loop based on changes to config setting is is a really powerful use case for AI so so that's something that's uh uh stay tuned right that's to come okay so uh so what I'll do now is I will um talk a little bit about the uh adoption journey and what we want to do is um is understand that you don't have to deploy this all at once there are various use cases that I'm going to take you through and then help you get started with just you know just let's say tracking of the configuration data okay so if we focus just on tracking um I I think you'll get a lot of value out of it very quickly and you'll be able to implement this uh very quickly okay so what what I mean by tracking is we capture the changes to the config settings and often these are going to be in like a yaml file or a Json file or an XML file that file is going to be part of your um you're you're uh you know your git repo and you'll have pipelines running against that repo that you know like build and test the application and eventually deploy the application so anytime it changes we're able to capture that data in Flight okay now uh validating it is extremely valuable as well because if something is invalid we'd want to know it we want to actually stop that pipeline to prevent bad config settings from being deployed to production right so if somebody uh and often there are a lot of use cases around keeping development settings from leaking into production I'll give you some examples developers like to turn debug on right because they get a lot of information about how the application is running in the development environment however if you leave debug turned on in production you're going to take a huge performance hit right you're going to have a huge problem with performance so so we want to make sure that debug is turned off another example developers like to uh they like to turn off certificate uh validation why because developers have a hard time getting valid certificates for their development environment they provision a new environment and now they need to request an SSL certificate sometimes it could take a few days so they simply turn off the validation of that certificate meaning the applications will talk to each other without concern for whether it's talking to the actual server because it's not validating the SSL certificate so they'll leave that setting turned on and that's a real example that happens all the time in in production environments and now the production environment is exposed to you know basically a vulnerability that would allow another instance of or somebody to spoof a connection to that application right so that's the type of thing we want to validate but also we could take it up to a higher level to like a governance level for example I'm going to show you an example of gdpr uh this is the European in um the European privacy regulations right and there are a lot of I.T settings involved in in compliance with those European uh compli European privacy laws and one example is you know we want to make sure if you have European customer data in a database uh you want to make sure you're not provisioning that database outside the EU right because that would violate the law so what we can do is we can ensure because servicenow has the information about the compliance rule in irm we have uh attributes about the application you know whether it's a regulated app whether it's a customer facing app whether uh you know it's the geography of that app where it's located these are cmdb attributes we have we can actually validate uh whether it's in compliance right because now we have the actual setting in the cloud formation template in the terraform file of wherever you're trying to provision that database we can validate that so that's an example of a higher level validation capability okay so we'll start off with tracking today validation could come at a later date but just get the data into the data model and start taking snapshots of it and that will be extremely valuable as well and I'll show you why and then management of this config data okay is very important because uh once you start centralizing it it starts making sense to actually use the data you have to generate the files that are necessary meaning we have the power and and it's a very powerful hierarchical data model we have the power to to utilize uh the information we have in the cmdb other data you have in the data model to actually generate config settings okay so proactively create the config files so that you wouldn't even have to ensure validation basically you're generating them from the system itself and and once you do that you reach the point of management uh config data management okay now that takes a little bit of effort that also takes you know in some ways a culture shift because everybody likes to manage their own config files and store them in the git repo but it is uh it it what it is very compelling and if you can convince your development teams to uh to utilize this and we're working very hard to make it easy for them to do that then it becomes a very powerful uh solution for you know for making sure that that config settings are valid in the production environment uh even right when they're created okay and then of course what I was talking about a few minutes ago leveraging AI generated config settings and validation policies uh based on this continuous observation of what's happening in production basically that feedback loop that's such an important part of devops and have that uh generate the you know have that feedback into future config settings okay so that's it I'm going to take you now into a demonstration of the uh of the product and I'm going to start here with the pipeline okay so right now you're looking at a uh Jenkins Pipeline and you might have seen this same pipeline if you're familiar with uh devops change velocity okay uh it's it's um it's a pipeline that we use to build an application run some testing on it run some validation on it run some functional testing and then eventually create a change record as you see here right and what we have in that change record uh is all of the results of all the testing and building and validation that took place just to ensure compliance with the change approval policies but what we're focused on today is devops config so what I'm going to show you is what we also have I know I mean open up another uh instance here what we also have and I'll bring up that change record is a snapshot of the config settings okay and and why is that snapshot important well I'll show you let me um let me show you let me get this out of the way uh uh this is my git repo these are settings I I changed right and I mean these are these are basically the cloud formation template these are the the all those settings for provisioning my application in the cloud and as you can see this one particular application it's essentially the front end of a web-based uh customer facing application uh you know has hundreds of lines of configuration data right so what we do is part of this Jenkins pipeline is we upload that file every single time the pipeline runs and then if it changes the data model that means if you had new settings in there we are going to create a snapshot and then we're going to validate that snapshot okay but more importantly is we're going to attach that snapshot that you see here if it's valid uh we are going to attach that snapshot to a change record okay so the change record has lots of information here it has the work items from jira it has all the commits from Git it has all my tests results all of these are capabilities that you know you can learn about in devops change velocity but for our purposes today what I'm showing you is we have us the snapshot okay and from here I could actually drill into that snapshot so show me the config data and uh let's see what it looks like in um in devops config okay so the config data like I said earlier is a hierarchical model of all of the config settings as they relate to this application now this is a specific deployment of an application so we only have a subset of the model we have the production environment in the US and then we have uh the cloud formation template file I just saw you and then automatically we build out all the different nodes of config data and I could put this in a list view so you can see what we have are the actual settings and parameters for ec2 instances lambdas rdsdbs S3 buckets okay so all of that data makes its way into um into the data model and that's what you'll see is is the subsets of that data so so it's very complex and it has uh quite a bit of data and uh you know there might be some Secrets here we have ways of obfuscating the secrets or we can encrypt the secrets at rest and you know using the platform encryption capabilities um we have ways of deduplicating the data right so in the data model if the same data shows up in a hundred different places but is only slightly different in those places and we can actually um use the same user symbolic link to the original data and have it override any settings you know specifically in the US or specifically in a production environment and so on so the data model itself is kind of the secret to the success of this product that's why it works so well is because of the way we model the data okay now let me show you another example of how we can use this so I'm going to go into my uh workspace here uh this is we'll go in into the service operations workspace this time got a lot of workspaces and servicenow and now I'm I'm like an incident manager right or someone in operations and an alert comes in and what happens when the alert comes in is uh basically servicenow does a really good job of trying to determine the root cause so it'll know that the alert came in and this could be from a tool like lightstep you know for observability uh in production or it could be from uh you know any any of the hundreds of other monitoring tools out there like uh datadog or something like that and we get these alerts and then what servicenow is going to do is look at all the recent changes to that service and based on those changes right we could actually then look uh that change record will have those config snapshots attached to it and we could actually look at the um at the actual this is taking a minute to load um we can actually look at the config data in in that snapshot okay so as an operator I could very quickly see what the settings are but the settings aren't going to make sense to me right what's really important to me is what changed right because that's going to help me determine root chord so I'm only going to show me the differences of the settings uh some things might not be significant and some things might be significant but if I look at only the differences it'll help me determine root cause but also I could go back to other snapshots I don't have to look at the two most recent snapshots I can say let's go back to January show me all the config data snapshots going back several months I could then go to the list here and say okay show me the one from January 9th to the one in August uh you know because sometimes you know a queue might slowly start filling up or you might start running out of space in in a segment or you might have a performance issue that grades over time so you really want to get to the the beginning of when that degradation happened right uh and and the idea here is that um you can you can compare any two snapshots in in the history of that of that CI okay so that's really valuable okay I see we have a a couple of questions I'm going to pause for a minute and answer a couple of questions the first question is uh what is light steps so light step is uh is a technology it's basically a monitoring tool for observability um and it uses uh Telemetry data from applications to uh measure uh performance and and errors and things like that uh and and it's owned by servicenow and uh you can use it for monitoring your application so that's the example I like to use them you know but there's there's tons of other ones out there like uh app Dynamics for example that do similar things um okay is service mapping required to have config data uh flow back to the app service so if you want it to flow back to the app service then yes you do have to have well no you don't have to have service mapping you just have to have the services defined okay because what we do is we link um what we call a Deployable in the config data model and think of the config data model as adjacent to the cmdb it's not really part of the cmdb but we link it to the cmdb it's adjacent to the cmdb and this application okay and I'll show you what that looks like here um this Deployable is going to be mapped to um map to that application service okay so if I click on manage deployables here you'll see that particular Deployable is can be mapped to various application Services okay so this is Globex prod the dev environment might be mapped to different ones that's mapped to a development version of the service and so on so that's the link right there that's the link between the Deployable at the top of the config data model I showed you and also the um the the application server so you don't need service mapping but you do need application services to find I hope that answered the question okay any any other questions before I move on okay so what I'm going to do now is I'm going to you know make a change to this config data and I'm gonna as I was explaining I'm gonna uh deploy this back I'm going to try to deploy this this database in a different region Us East one I'm going to go ahead and commit that change and I'm going to now go ahead and then um run another uh Jenkins job here and what you'll see is this time when it runs it's kind of fair and if it doesn't do it in a timely manner I'll show you one of the older ones but in the meantime let me show you uh the connection between the config validation and the um irm Solutions so we want to go into the compliance workspace here and what you have in the com in compliance if you're not familiar with it you have basically these Authority documents which are like rules like ISO 27000 cobit gdpr uh and all these regulations that you might be under because of the industry you're in if you're a financial company or if you're an insurance company uh you'll have these regulations and then under that you'll have control objectives okay control objectives uh roll up to those uh higher level Authority documents and then within the control objectives you might have something like maintain gdpr right so it maintains gdpr now underneath that control objective you're going to have a whole bunch of controls and most of these controls I would say you know most of the time a lot of them uh are not automated right A lot of them are are like at test stations where a developer or a uh you know some it person actually gets an email they check a box and it basically says now did you run the security scan yes I did you checked the box and and you were tested to the fact that you did it did you set you know are all your uh websites using you know 256 bits uh encryption on your certificates and so they they attest to uh the controls but what we have now is the ability to map this config validation policies right and the policies uh like validating the region of that AWS setting uh is definitely a control to maintain gdpr compliance so what happens now when that pipeline runs and reaches a point uh this one's waiting for a queue that means it's too much running here let me show you a previous one here like this one when it reaches a point where something fails nope not that one let me cancel one and we can get this one to run correctly when it reaches the point where something is um validated then uh it's gonna say hey this this particular snapshot is invalid okay and it's invalid because you know you have various policies on it and what those policies mean is anytime a new snapshot is created we have to um validate the policies okay so when you have Snapchats you'll see some of them failed validation some of them pass validation if we look at one that failed and this was a previous run uh you can see all the validation results meaning all the rules uh certificates were valid there's no FTP uh consentings there's no HTTP settings you know we want to make sure that all the URLs that connect use https instead of HTTP we want to make sure that multiple you know availability zones are all configured so on and so forth sometimes you want to make sure that that there are no duplicate keys right that sometimes uh that you might have two of the same exact config settings uh and and so um yeah so so this is how this works uh you you get these rules that run against the snapshot in this case this one failed because you know we tried to use Us East in the pipeline okay and U.S east isn't allowed because of the gdpr compliance all the databases have to be deployed in EU regions because they contain European customer data so this is this is how we enforce that in the Jenkins Pipeline and what we call this is Shifting um shifting compliance left okay so we're shifting compliance left we're discovering things happening in the earlier environments that are at a compliant and this is why uh this is why um you know we can keep bad settings uh and and focus on uh keeping that out of production okay so that's what devops config is all about there we go we have our failed validation and if I look at the test results and what's great is we report this back in in the pipeline right if using a Jenkins pipeline if you're using an Ado pipeline if you're using GitHub actions uh you'll see the results of the validation it says us for aw key region is not compliant so right away the developer knows why the pipeline failed and they could do two things right they can fix it here okay but there's also if you're familiar with irm anytime something fails you have you do have the ability to request an exception so somebody on the devops I can say okay we just need this to work for a short period of time request an exception and then that will allow the pipeline to continue but with an exception okay it won't fail so you can either fix it or request an exception the exception will kick off a workflow an irm to have somebody approve it okay okay so that's what devops config is all about tracking and validating config data um and I think before we go into how do you get started with this uh I'm gonna take um a couple of more questions here okay to get started what plugins are needed well I'm going to show you exactly which plugins you need in just a minute so hold tight there and the second question is also do we have to activate a plug-in to have devops config applications activate in instance yes so I'm going to show you exactly that's those are good questions right now because that's what I need to uh transition to uh uh okay so plugins let's talk about the plugins you need Okay um you there there's two main uh products under in The devops Bu for service now this devops change velocity uh and then there's devops config okay devops if you do a search on devops devops change velocity uh is not really a prerequisite but I would recommend installing it because it gives you uh the ability to register the plugins that you need in the pipelines okay so you need to install plugins on the servicenow side but you also need to install plugins in the in the orchestrators okay so and devops can change gives you all of these settings and everything for that so you should install if you're going to use the plugins you should I do recommend installing change velocity you don't have to implement it per se you just need the tables to to recognize the uh the plugins in the um in the pipelines okay so devops change velocity is one thing and then devops config now I would recommend using these green bundled installs because each one has a bunch of apps that will install uh same thing with devops config install this green bundle and you'll see there's like seven apps underneath it and the current versions that are available are here two point three and devops config is uh uh um there as well so all of this gets installed when you install the bundle so that's what gets installed on the servicenow side I should point out there's a new component called policy it was code engine when we run um the policies okay and let me show you what what I mean by that if I click on one of these policies uh the actual policy uh uses um uses uh JavaScript thing and and and and and let me go into the devops config workspace and I'll show you what a policy looks like uh the policy for is actually written in JavaScript so we give you a bunch of them out of the box right like you know it's 40 or 50 of them now I see here um and and what you can do is you can create your own and it takes a little bit of javascripting knowledge or you know you can you can actually Google a lot of things you can do in JavaScript but it's a very powerful language and if you've been doing anything in service now you're probably doing some JavaScript and anyway but the policy are all written in JavaScript and this is what the policies look like and there are different versions of them as you can see here so that is the um policy is code engine and there are several other modules that serviced now taking advantage of policy as code so you know you've seen policies in a lot of different ways in servicenow the trend in the industry is to move towards policy is code because of flexibility and and you know basically a lot of the things that are going on in devops the agility of it uh and then uh you can do that now with uh which service now okay so those those are really the only two plugins you need devops config and devops change velocity now there there are okay and then you have the policy content that's included okay that'll give you policies we didn't really talk too much about the exporters but the exporters are also written in JavaScript okay uh and so those are the those are the um so I hope they answered the questions about the plugins uh any more questions uh okay how is the Jenkins pipeline invoke with the config data from servicenow okay typically pipelines are not invoked by service now right uh pipelines run when things change in the repos okay so often uh you'll have what's called continuous deployment meaning anytime you make any commit to a file in a repo it'll trigger a pipeline run and if the pipeline makes it all the way to production you'll get a change record and if the change records automatically approved it'll get deployed okay so pipelines are triggered by activity happening in the pipelines okay so we're not doing any triggering from servicenow what we're doing is we're capturing all of the results that that took place in the pipeline the testing the scanning the security scans and of course the config data that you see right here okay so um that's that's essentially how it works you know most pipelines never make it to production so you wouldn't want to have to go through servicenow to trigger Pipelines they're just part of the Agile development process now that pipelines are running all the time sometimes a pipeline if the build takes a long time the pipeline will run like once at the end of the day so all the developers will check in their code and then the pipeline will run you know at the end of the day at six o'clock and go ahead and create a build and test and deploy it okay okay uh what's the ocm for turning this on and making it mandatory for policy compliance um well so I think the um what makes it mandatory for policy compliance is the is the integration with change management because if you already have change velocity in place that means they can't get the production deployment until this change is approved right so if I go in here and I go into that change record I actually have to approve the change uh or it's automatically accrued for that change to get into production and what you can do is you can enforce the um that the config data is valid uh that is past validation you see here that could be one of your uh one of the criterias for your approval policy right um so that's one way to uh enforce and make it mandatory um and developers generally like to have their things deployed to production quickly so you know they're more than happy to upload the data in their Pipeline and make sure that it's compliant if they want to get through the change approval process and of course you know we've added change approval uh automation to servicenow using the change approval policies so that you know this could take even a minute less than a minute for this change to get approved in this case we didn't meet the criteria for an automatic Improvement so I got to override that I'm going to move this to the implementation stage and then that will allow this Jenkins pipeline to deploy to production okay any other questions okay I don't see any other questions here so I am going to go ahead and let's talk about uh the next step on um how do we get started here how do we get going with this uh so let me bring up this is the basically the steps okay so we are um install the necessary plugins uh we just covered that and what I'm going to do now is show you that the next step is basically to create an application uh and a Deployable right so what that means is in devops config we are going to okay this is deploying now because the change was approved by me you see and that gets recorded in the pipeline just wanted to show you how that works if you haven't seen that before uh okay so back to devops config uh what we have are applications that are and and this we covered earlier these applications are mapped to deployables underneath and then those deployables are mapped to application Services right so if I wanted to create a new one and let's say I have a new application with a new pipeline that I want to upload data from uh I'm going to go ahead and say okay let's call this um um GSW one for getting started workshop and I'm going to go in and create it now I can now uh create the application I can use uh an existing application model on an application service and it'll allow me to select that service uh from from here okay from the list right no there's none found here okay application model and then I can basically uh use let's say that portfolio model and create that so now I have the application created and we're going to now create some deployables now remember a Deployable usually represents an environment so I'm going to create I'm not in the right application here I'm going to create I'm going to go back to that new one I just created and bring up that one and and so the Deployable can really represent anything but best practice would have it represent uh let's go with the corpse site would have it represent um a an application and environment right so this will be the development environment for Co-Op site uh okay go ahead and create another one let's call it the uh the test environment for Co-Op site and this will track the config settings in that environment and now let's create one for the production environment okay and the production environment is usually where we're going to apply some validation rules okay so now we have basically the schema in the config data model where I can now upload data to these deployables and map them to the deployables okay so once you have this in place uh the next step is to okay let's identify the source or config data and and since we're talking about devops and devops pipelines the source of the config data is usually going to be some type of git repo okay so in this one I have an infrastructure folder uh I have um various uh there's some kubernetes Helm charts in here there's some there's a mongodb uh config data here and Json I have some yaml files uh I have some XML files uh and so so there's various types of config data I can pull from and what I've done in my Jenkins pipeline right and let me show you what that looks like is um we add a directive to the pipeline so this is what your devops people will have to do uh is once you install the plug-in in Jenkins and let me show you in Jenkins what that looks like um Jenkins has plugins just like servicenow has plugins so if you go to the uh the plugin manager in Jenkins and it's the same thing in Ado and you search for a service now uh you'll see servicenow devops okay uh if you're doing uh ado same idea you'll see um in in the extensions you will see in the organization settings extensions you will see the servicenow devops extension right so that's the the and you just want to make sure you have the latest version of that extension and that'll make sure that when you call the uh directive it'll have the extension behind it to you know to know what to do and when I say called the directive what I mean is inside the pipeline file if you're doing pipeline as code or if you're doing classic pipelines you'll need a directive to um first upload the config files now you can do this in a wild card way you can say give me all the Json files and recursively search all the directories for example or you can say give me a specific file and it'll upload that and that's really all you need to do to get to the first um the uh that first step in that model is tracking the config data all you need to do is basically upload the file and every time it changes um we are going to snapshot it into servicenow so what do you need to upload well you need the application name right which you just created uh you need the um the plugin configured so let me let me show you that once the plugin is installed you're going to have to configure it in the case of Jenkins basically what that means is you have to give it a URL and some some settings um the URL and and there's an integration user you can use or there's a token you can use and you can set the plugin to use those uh their settings just like anything else in Jenkins it connects to tools it's going to have settings here there's the service now and there's my URL and these are the tool IDs and then Jenkins has a way of storing the credentials in a secret so you can just refer to the credential record I'm using the devops integration user for example when you install the tool you'll see it'll give you assist ID for the orchestration tool you want to make sure you put that here that'll help tie everything together so now you have the plugin installed and then in the uh Jenkins file and you you'll have to refer to it's going to know to use that connection to upload the data that you specified here okay so that's that step any questions so far no more questions okay so this is all crystal clear okay the the the the next step is to um Okay add directives to your pipeline that's what I just showed you right so if you're using uh Jenkins I showed you let me show you in in servicenow it's something very similar so I mean in um Ado it's it's something very similar you'll have a directive in the pipeline uh pipeline here let's show you what that director looks like uh you're going to want to upload the uh config data right it looks just like it does in Jenkins basically the same inputs uh where are you uploading it what type in this case I'm doing it in a wild card way so give me all the Json files you can find in all the directories in the repo and upload them when they get uploaded to servicenow it'll build out the directory model as nodes in the config data model so it's very neat and then uh anytime something changes in those files you're going to get a new snapshot okay so that's those are the directors you need so so you create the application in the directive you're going to point to the application and point to where in the in the application you want to upload the data and then for the last step and this is an important step if you want to do that use case that I showed you earlier you want to register the config snapshot with a change record um this the this record this has a dependency on devops change velocity okay unless you want to manually create change records we do have API calls that you can use to do that but you know devops change velocity already does that for you already creates the change record automatically it's a very comprehensive change record with all the work items commits all the defects all the security scans and so on um basically in that same directive okay we're gonna actually point it to the um snapshot okay so that's one of the inputs is the snapshot name that gets generated earlier in the pipeline okay now if if uh um if there are any uh let's see if there are any other questions about this uh you can post them to the Q a but that's pretty much all you need to get started with the first use case of tracking the config data okay uh I did create a series of videos on YouTube if you go to uh the servicenow Youtube page you do a search for devops config basically what I just showed you how to do the tracking and also I just released another one on validation so that should help okay okay what's the question the question is what type of authentication do the plugins use that's a good question so the plugins use two types of authentication there's uh um an API token based authentication and then there's also a basic authentication where you store a user password in the tool and then it can reference that as a as a record to to make the API call using the user and password so you have either one of those options you use an API key or to use the basic authentication with a user and password okay is that I hope that answers the questions all right so I hope that was valuable if there are no more questions um I think I'm going to wrap it up here and uh I hope that was valuable if you if you do have any more questions you can you can find me at joe.offenberg at servicenow.com and you can reach out to servicenow through your account team and uh uh oh somebody's asking for the link to the video uh let me see if I can find that quickly and put that in the chat just bear with me one second but um yeah that's sorry that would be a good idea to have that in my slide deck and I didn't have it uh let's see here okay here's the video and I put it in the chat and and it's called if you got it there it goes uh if you have itsm Pro you own it so basically you get get started with uh devops config oh I'm I didn't I didn't send it to everybody hold on I got to send it to everybody okay now you should have the link in the chat but uh it's uh it's pretty easy to find with a Google search that's basically how I I found it yeah all right so I think we're going to wrap up here thank you everybody for uh joining the webinar and you know go uh go set up a sub prod environment and start playing around with this stuff it's pretty easy to get started and if you need any help uh you can reach out to me through your account team thank you