 Okay Hello and welcome everyone. Thanks for joining us today. We are really excited to have you on in this webcast We're going to be covering a really interesting topic We're going to cover rich change controls for building workflows. You can trust my name is Joel I lead a solutions architect team here at GitLab, and I'm joining you from Chicago today where it's finally stops knowing We'd love to hear where you're turning tuning in from so feel free to use the chat function to say hi Tell us where you're from Before we get started just a couple real quick housekeeping items first feel free to ask questions throughout the presentation You can use the Q&A function at the bottom of your screen for that Also, we have dedicated time for questions at the end of the webcast You can go ahead and send your questions any time as you think of them and we'll be sure to get to those at the end If you're experiencing any technical difficulties, you can also use the chat function to get in touch with me For help on the moderator our presenter today is Darwin Sanoi a GitLab senior solutions architect from Pennsylvania We'll also launch a poll or two throughout the podcast or the webcast here So we can learn more about you and that way Darwin can also tailor his presentation accordingly So with that I'm going to just launch our first poll to ask you as a user of GitLab what Version of GitLab you might be using and with that I'm going to turn the presentation over to Darwin Darwin Who's they really excited to deliver this content to you today? As a senior solutions architect at GitLab. It is my job But also my pleasure to help customers understand how to adapt the many different Widgets in the GitLab toolbox to facilitate their get DevOps transformations and their DevOps workflows So GitLab has a lot of rich controls that you can apply but it kind of tends to end up being like a box of Legos That's all mixed up and I used to play with Legos as a kid that big box of Legos and Sometimes you don't know all of what's available to you So we're going to take you through and try to give you some information on exactly what's available to you And then sometimes you don't know what you can make what's with what's available to you So we're also going to show you some patterns what you might make with those controls And some of these controls are used in a little bit different way because GitLab is a GitOps oriented system when it comes to supporting deployment So with that, let's jump right in We're going to go through a bit of an agenda here and see some of the things that we're going to cover So first of all, we'll talk about custom user groups and custom user groups are something that we can create inside of GitLab You're familiar with seeing users mixed into groups with repositories But it is possible to create specific groups that are dedicated just to managing users and Create them in a kind of structure that's very similar to operating system groups, which you may have had experience with So we'll take a look at what you can do there That's important because custom user groups can then be used in many of our gating controls and our gating controls cover both code Collaboration so making sure your code is good as well as deployment control So making sure that things are being deployed to the right environments in a proper way So we have to use those gating controls for both of those types of activities when we're doing the full DevOps lifecycle inside of the tool We'll then talk about repos and merge requests as workflow building blocks So you may not be aware that there's several features that go over top of multiple repositories Which allow us to then use repositories as sort of a workflow building block So we don't have to keep all of our workflow in a single repository Even though we may be using a code base to target many environments We'll also talk a little bit about enabling de facto development patterns So if you're doing microservices or other patterns, you may wonder if these are possible and what some of the options are within GitLab and so we'll show you a few patterns that are possible once we give you the component tree We'll show you some pre assemblages of it kind of like that picture in the back of the lego's box It shows you hey, this is what it should look like when you're done and then finally we'll talk about Just basically reviewing a table of controls by their GitLab addition So at what GitLab addition do they become available and then also their scope So what do they affect an entire repo multiple repos just emerge request a single file in a repository So give you that scope information and then we'll also indicate where custom group support is available within those controls So let's talk just a little bit about custom user groups because they're a fundamental part of what we'll be talking about So the history of group structures in Git collaborative solutions is really that we only had one resource type repositories So it really evolved that we hey, we have some groups of repositories and we want to group them together And then we want to assign users to be able to manage the repositories within that group or manage within the individual repository And so that's kind of why the Git collaborative solutions all have this kind of effect where If you come from the operating system world, you're like, well, hey, where's the user groups? Why are they all mixed in with the resources? It's because there was really only one resource type to manage So over time, GitLab has developed the capability to have the resource groups separated from user management groups Custom user groups can be used in many different places for gating controls And so we move to the next slide. You'll see the term custom user groups Used or custom groups. I think I used throughout the slide and that's how you know when these things can be used And we can also create a dedicated groups hierarchy just for users So we separate our groups of users from our repositories and then assign them in users And if you've been doing operating system groups, you know, this is the best practice right off the bat Don't assign users to individual resources. No, instead we want to always assign them to groups To what degree you adhere to that kind of operating system orientation or Directory group orientation will be up to you, but we'll at least give you the enablement to be able to do that So within a group if you check in a group that you have a maintainer or higher permissions to and you look into its settings There'll be a subsection for permissions and these two little permissions are kind of looking innocuous like they don't do much But they're actually quite powerful. So the first one allowed to create groups This is set to maintainers by default And you can up it or I'm sorry, I'm sorry It's set by to developers by default and you can up it to maintainers or say no one can create groups And as soon as you do that you eliminate the risk that someone starts creating repositories in a structure that you consider for users only The other control you have is allowed to create subgroups And this is set to maintainers by default And you can set it to owners and then make sure the only people that are owners And any of these groups are the people who are responsible for administering the group the set of groups And that can tailor that down so that no one's creating structures that you don't want Also, you can delegate group membership management. So if you're like, hey, we got 50 teams here I'm not interested in being constantly having tickets come in to add this user to that group If you make a user a maintainer of one of these groups, then they can add and remove users from that group So you can essentially delegate that membership management In addition, it's important to keep in mind that the source group role has no bearing on new assignments So if I have a group of 20 users and I've made Five of them developers and one of them a maintainer and I reassign it to a new group and say, hey, over here You're just a reporter. This group is a reporter inside of this repository Well, then they only have reporter in that repository So the original permissions they have in the original group do not sort of flow through to a new membership assignment Or a new permission that we assign on any of the controls that you'll see that we talk about today And finally, one of the things that's not so helpful is the group memberships Inside of get collaborative systems flow down the hierarchy So if you make someone a member of a group and it has three subgroups or automatically a member of those subgroups And so one of the things you want to keep in mind is to not put people in those intermediary groups It's actually best if you create your structure. So there's no need to ever put someone In some sort of intermediary or higher up group that all memberships go in the lowest level groups So if you were to create a structure yourself That's dedicated to users only then it might look something like this if you've been around operating system groups for a while You can see here. I've tried to help people understand with no users in this group That's just the description of the group and it's making making a declaration both that no users should be added If you're an admin and it's also making a declaration if you go to select this group somewhere That there's no users in it. So don't use it But that might be hard for people to remember because the description is not always displaying whenever we go to select the group So while this structure is tempting And it might be necessary if you do so you have to be sure that everyone understands you only ever assign users to the bottom level groups And then you'll also need a kind of a Group in the case of sre's here. You can see we have an all sre's group. So that's the one that actually contains all the sre's Not the group above it and then any breakouts we have of Individual sre's for different purposes. We would create subgroups underneath that group Probably a better structure if you can handle it. So if you don't have 7,000 groups and it becomes really hard to to manage Is to have a flat structure and here we can see that the naming convention kind of indicates a hierarchy So we can see we do have qa groups and we have info security groups and they sort together because they're named similarly But in this case, we don't have to remember that we can't add users to intermediary intermediary groups because there aren't any And so that's another way to handle this Challenge Take a look at the screen at both of them and they have a prod approvers group in various different areas And what this is emphasizing is that when we deploy to an environment We want to maybe have special users that are production approvers and only they can do production approvals Now if you have the premium or up level product, then you can do multiple people from different group sets So you can say I want one production approver from sre's one production approvers From security and two production approvers from application a In the starter product You can only specify one set of groups and users and roles and then a total number of approvers for that So you just have one approval rule So in that case, you'd probably want to have something like app a production approvers and then add someone from security add someone from From sre's and a few developers or the entire development team That's a little bit more manual and you can't have the delegated permissions, but at least you can still accomplish Somewhat like that, but of course if you say I want four approvers and there's 20 people in there Someone could leave out someone from security So premium gives you a lot more flexibility in controlling a bunch of rules for different user groups and and how many approvals you need from each So that's the concept of custom user groups. It's fairly Strong in git lab all you have to do is to use the custom user groups To do is say hey, we're going to create a structure. It only contains users Then turn on these two settings and all of those groups and start Controlling how users are added to those groups and then use those groups whenever you're assigning permissions to your repository groups We're going to shift gears now and talk a little bit about the gating controls that we have Now because git lab is a git ops oriented product and supports the full dev ops life cycle It has these gating controls both for code review Which is something that you're familiar with all code systems Source control management systems have this kind of concept of let's collaborate and make better code changes and Ensure that everybody's approved it and everything but then also environment change control becomes a concern for deployment So when we do a deployment, we also can use these same gating controls to control deployments So we'll start with the the initial and well known model of using it for code integration So we have our one code integration branch here Which is where we'd hope that all developers merge their feature branches before they go any further And the first control set that we have Is a push rule push rule and pre commit hooks actually and push rules are like a firewall for our repository So they basically say I don't ever ever want to see this in my repository And I don't want anyone to be allowed to commit it if they have it there a great example secrets So committing some aws keys into the repository is a problem Now we could look for them in ci and say hey if you find any keys flag it fail to build The problem is we may not have a build set up on that branch Or we do find it and we do decide we're going to fix it But now in git in order to completely cleanse that secret forever We have to go in and force rewrite history, which is a usually a no-no for most organizations get flow So it's a very bad thing for those credentials to even hit the repository one time So in push rules we can say this isn't going to happen Now when you move up to the premium lever level you get two new Push rules that are available to you and that's verified committers So technically in git I can put some information in my local git client that says i'm joe blow who works over another company or Another part of my company and then make commits and then I can push those to my repository and it will look like someone else Is responsible for those commits Verified committers says if you're logged into git lab and pushing a commit That better be the identity that has been used in your commits or i'm going to block you So it basically says I want to know that only that you're the one who's either you either created this code Or you're taking full responsibility for it We don't want to have any accidental or purposeful identification misidentifications of who made the code Signed commits says that we're going to sign the commits with code signing So that we know that that commit as you committed it has not been played with since it's been sitting in your local repo And before I got pushed into our master copy on the on the server So signed commits and verified committers together gives you a very high level of traceability of a code change Right back to an individual and this can be important for some organizations if they deal with a lot of contractors And they really want to know what's been going on in terms of commits Or if you work for any highly secure organization or government organization where it's really important to know Where the code came from right down to the fingers that tapped it out So this is a great set of features if you have any of those kind of needs another control which is a Pre-commit hook is locked files and directories You can think of this as a person putting a semaphore on a file across the entire repo They're basically saying i'm going to be playing with this file I don't want anyone else to be able to commit to any branch anywhere in the repo if it contains this file Because only one of us is supposed to play with it at a time And so locked files and directories is a feature that allows you to Do exactly that make sure that you and only you can change this file from the time you You put the lock on it until you release the lock So now we start getting some feature builds and of course different developers are working on different features They commit their features up to Get lab and then we have the capability to start working with them with the ci cd components of the system One of the cool things with get lab is for free you get enterprise capable production ready Full on ci and that capability is very Very strong you can craft all kinds of different workflows that you might need We demo certain ones and we have certain automatic ones, but really you can craft just about anything you need to with this Within get lab ci. We also have something called a manual Phase so we can set up a job as when manual and what that'll do is cause that job to pause and either a human has to come And press play on it Or we have to call an api to get it going again And this can give us some gating of the process where it pauses the pipeline And this is different than a container waiting in a polling state because if that container were to die Or we start getting 5 000 containers in waiting states because they're waiting for something to happen for a week each That could be a big problem. So this kind of pause is really happening at the workflow level So there's no container waiting around just get lab itself knows. Hey, this pipeline is on pause until someone Continues it. So that's really a decent gating control, but there's no assignment of users about it basically people who are a repo maintainer or if you open up developer can press that play button But it's not assignable. So we know who pressed the play button necessarily and Require certain people review it before they press the play button Want to get labs great strengths is dynamic review environments We do put a lot of emphasis on our kubernetes support because it can be so full featured and Security cordoned off from everything else, but we also support dynamic review environments with regular web servers So if you deploy a web server and knit it together with your git lab workflow Then it can deploy to a sub folder have a sub domain published and you can see that review app and play with it So that opens up a whole rich world of doing review apps for things that are not containers and or not kubernetes One of the things that we'll just mention briefly is a security and compliance scanning and dashboard that you get with the ultimate package This allows you to start seeing some problems at the repo level and later on we'll talk about at higher levels as well To understand what kind of security challenges your code bases are undergoing And so today we're talking mostly about premium and moving from starter to premium But that's one feature we wanted to let you know about if you have a lot of security concerns So when we go to merge a feature branch into our code integration branch is when we start to have some of our controls and in git lab the Single source of truth or the ultimate view of change management is the merge request And any merge request is where we start kicking in various features that allow you to be able to get a lot of controls So in starter we have merge approvals, which is simply the ability to say I require at least x number of people to say they approve out of this set of users groups or roles within the repository and you can set one number for one rule and it can include Two users a role of developer in the repository and three groups from another place But it's just one set for the entire set of individuals that you identify Then tag protections are also available. So a lot of people use tags to indicate very important things about code Like an official version number official release number So we can also add tag protections with custom groups With the starter version and that will help us protect tags from being updated for the specific Users so users can't move a version tag unless they're in that group Premium adds multiple approval rules So I just mentioned that briefly before if you want one from iso one from sre and three from the development team And someone else to speak into this particular review Well, then you can specify them separately in those rules and all the rules have to be met before The merge will be allowed to proceed Now a lot of our controls happen in merges and there's more of them that we'll talk about in the tables That indicate the different features that we have at the merge approval level But those are some of the highlights and the premium highlight Then when we go into after we done our code review and we go to push code Only certain people are allowed to merge the code and this is called branch protections So when only certain people are allowed to merge it we can also specify custom groups in here So we can say one custom group only people in say production approvers or Final code review are allowed to merge to this branch Then we can have even more control and that is a starter feature Then we can also have ci and it offers many of these branches as we wish So this is just showing you that hey the whole ci workflow that we talked about earlier Is also available off our integration branch and of course we can also flow back And figure out if that Review if this merge is going to succeed or have a problem One of those premium features that we'll touch on later is that when you do this merge You definitely can fail a build But maybe we want to not allow the merge unless that build is going to succeed So how do we do a predictive build? So we have something called builds for merges that does a separate build as if the code was merged before merging it So just right on your ci agent It's going to merge the code and run the build and be able to tell you whether that's going to succeed or fail without Actually merging the code, which is a really awesome feature So you can then say builds have to succeed and by the way my merge commit build failed So I without even merging it. I know that it's going to fail. So that's really powerful for merge merge approvals Then if we are if this particular repo also supports deployments. Oh, I'm sorry I don't want to skip over this over here. We also have protected environment gating with premium So when you deploy to an environment, you can say only these individuals can actually do that final stage of deploying to a given environment It's similar to branch protections, but it's oriented around the target environment that you're pointed at And so this is another way to start controlling Who is exactly allowed to push to certain department environments now usually on an integration branch or especially feature branches You don't care like feature branches You want every developer is building code to build to push out to that Environment because it's isolated and you want to see if it's working But as we get further and closer towards production, you usually want this more and more constrained So that's a premium feature as well Now with get ops, we're going to start using branches now for deployment So and you know that you use branches for code development But even once code is done developing we can start to use branches and merging to deploy it to production environments And so in this case we can have individual gates that have to do with those branches At the branch protection level so our merge approvals the big great gate applies to every branch and then our branch protections can apply to individual branches If you need something where you need merge approvals that are different by branch Well, then we could separate it into different repositories and start to get that particular granularity So some of the things we have at the branch protections level for for free You have a branch protections by role So you can say brand only developers can merge to this or only Maintainers can merge to this branch Then in starter we have users and custom groups can be specified and finally in premium code owners can be specified Now code owners is something that's developed Within the git community around having more control over specific files So sometimes some files are so Important or so specific that we want only certain users to be allowed To approve those changes to those files or groups of users and so code owners can be Set up as a branch protection that if you know amongst all the merge approvals that you gave No code owner was specified or no code owner approved it for x y z file Which has a code owner identified then we're going to block you you have to get at least one merge approval from that individual And that's also a premium feature Also, you can see that we can use custom groups in branch protections So you can also use custom groups for code owners So Just drop back one slide. So this is a lot of information a lot of gating controls So this is kind of like your pile of Legos and what all the different pieces and parts might do But because we unpacked it slowly, I'm hoping that you kind of get a concept of where some of these things can be used We're not going to use these ideas and try to block them together to help you understand some other features of the system So if we have an entire repository workflow and we want to start linking repositories together And also linking different merge requests together. We can start to get some new functionality One of the things we add in premium is an ops dashboard. So all these operating environments You can check out what versions deployed there. How healthy are they? What was the last deployment and so you can create that ops dashboard over all the operating environments in a repository We also have something called merge trains and merge trains are when multiple merge requests need to succeed as a group In order for us to continue But we have no ordered dependencies So we say hey these three merge requests need to complete successfully so that we can move forward But we don't want to wait for each one because then someone's going to make another commit and the whole thing is going to start Over again. We want to get through them as quickly as possible and since we have no sequence dependencies Let's just run them in parallel and that's basically what a merge train is it lets you associate those Together and it's within the context of repository. So in this case three merge requests in the same repository We also may have multiple repositories. So if we start linking repositories together to get certain effects microservices is one example that we might do this for Then we can start using environment roll-up dashboards and these allow the various environments across many projects to roll up in a group context So we can start seeing what's going on across multiple environments In addition, the security and compliance roll up rolls up as well And it rolls up as many group levels as you have And then we can start using something called merge request dependencies And merge request dependencies can be within the same repository or cross repositories And what this basically lets us do is to start to link repositories We're saying these merge requests depend on one another, but they're also sequentially dependent So merge request one and repo one would have to complete successfully For merge request two in repository one to go ahead and then be capable of completing And so on so all of these dependencies are sequential and have to wait for the build steps of the previous merge to complete So those are merge dependencies And we have a little bit of more information about each one of these So that's some of the ways we can start then using repositories and merge requests to be a workflow control across multiple repositories So let's talk a little bit about some patterns. What we have here is a microservice pattern That is 12 factor compliant And if you're familiar with 12 factor, it basically says that for each microservice, you're going to have a repository And when you have a repository for each one, you'll also be able to deploy independently or dependently So you can say, hey, we updated two Services and both need to be updated in order for this new functionality to work Then you can link those together in this case with merge request dependencies Or you can also have these deploying independently if your microservices are that Independent of one another so a 12 factor microservice capability no problem Also, you might have a situation we have customers who are software companies And they have to deploy the same exact software to multiple stacks Sometimes this is customer tenants So every customer has their own kind of stand up and they need to build a Very the version by customer only update the customer and the customer's ready So this is showing three repositories each generating artifacts And then those artifacts being reused in deployment only repositories And so we can have those merge controls available in order to push that code out A lot of times this has to do with individual customer config So the all that would be in the environment deployment repositories would be anything that's specific to a customer And if it's been boiled down to be just config files, then those merges would allow this to proceed And you can have the additional merge controls another possible scenario is having Repos as building blocks for cd push only So a lot of people are familiar with products that only do CD and they are very sophisticated around just getting code artifacts out And this is another thing that can be done in git lab as well So as you've seen this flow, we know that at the end of the day on our production line at the bottom We can go ahead and push through an environment But what you may not know is we could also push with some different tags and target a different environment Maybe with a different version And so we don't really have any kind of limitation on how many times we do a deploy Once we do a build so in this way we can have One you know a more a situation where we have a lot of target environments for the same exact build What we do potentially lose here is our merge request Capabilities so at this point, we only really have protected environments capability So list of list of users or a group of users that are able to approve this push And that's the only control we have so if you need more collaboration You'd want to drive this back to a merge request in order to enable it But we can do this model as well So let's take a look so that's kind of some patterns as well as some of the capabilities I want to go through now a kind of a table view of the control scope Whether we have group capability and what addition each of these capabilities comes into So on the screen here, we've covered most of this already One that we haven't covered is resetting approvals when code is pushed So you can go ahead and say hey if someone pushes a new commit reset all the approvals Everybody's got to approve again high impact, but it might be necessary depending on your situation You can say pipelines must succeed and this is where we can also link this with the premium feature of pre-merge pipelines So the pre-merge pipeline must succeed in order for us to approve a merge request All review discussions must be resolved is where we say hey if someone started some concerns When you comment your code in review in a merge request, you can either create it as a comment Which is basically hey here's some info or you can hit start review and when you do that process You're basically saying I don't want you to ignore my input I want you to work through it and then we'll hit resolve Discussion when everybody's happy and so that is supported with core as well Um, finally preventing merge preventing anyone who either authored the merge request or authored any of the code From being a unapprover So you're basically saying hey if you're the ones promoting this change or trying to get it through We're going to just say that it has to be completely other people that approve it So we get a lot of eyes reviewing it. We don't have basically the curse of expertise if you've been working on a bit of code for A week straight. Guess what? You're not the best person to review it because if there's some mistakes in it You've already looked at the mistakes a thousand times and we'll probably let them through So those are some of the new bits And that's in core and starter in premium. We have a lot of other things that we add and some of the most of these we've discussed One that we haven't discussed is merge request reviews So I don't know if you've had this experience, but I've gone in made a comment on someone's code and said Hey, you really ought to consider xyz Goed four lines down in the diff and see there's where they considered xyz So guess who looks dumb and has to erase the comment or say, oh, I see it's already handled Meanwhile, everyone's gotten an email saying that you have a code concern So merge request reviews allow you to bulk edit all of your comments at once and then publish them all at once So that you can make sure they're consistent within themselves So that's a really helpful feature And I think we talked about everything else on this slide Oh, I guess overriding merge request approvals. So Normally merge request approvals you set them in the repository and every merge request created in that repository must comply And it's a point of policy if it doesn't comply. It doesn't work However, if you change this setting, you're basically saying these are actually the suggested configuration I trust the person who's allowed to make merge requests to make alterations and say, you know, we're updating documentation I don't think anyone from security really want to spend the time to approve that So you can knock off the approvers for security for docs only changes would be an example And then finally some more premium features. We didn't cover this in the Graphics that we went through but audit is a big emphasis in premium So you can create audit users and that's a new class of user We have users and admins and then when you premium you have a class called audit And when you use that those users have read access to everything in your instance or group structure And what that allows them to do is to do their job of auditing code or maybe security security audits without having to be added to every repository in the system We also have audit events that are in the GUI So you can see when people change things So if someone's a maintainer and they go change a group so that they go change a setting so that they can add a subgroup Then add the subgroup and then change the setting back so that it doesn't look like they have the setting You're going to have an audit event and be able to understand what that happened I also didn't mention that in all merge requests you have audit events automatically added to the log all the time So people check a checkbox in a Markdown checkbox. It's in the body of the merge request It records that and you can see who checked it or unchecked it and when So there's audit capability built ready at that level as well We also have additional audits events that are available through the api and you get those with premium And then just dropping down we cover protect environments all of those and then security approvals and license compliance approvals basically if You can set the whole instance so that if someone is Accepting codes the developers are allowed to say ignore this vulnerability But if they do that on a vulnerability that has not been reviewed by security before then we can require that security Must do an approval we can do the same if they accept a blacklisted license So the license has been blacklisted someone decides, you know what I'm just going to slip this one through All of a sudden security has to be able to review that So that's the kind of the view of all the little features and functions and some of the places where you can use them The inflection points where you can use them in your workflow to start to take some control over these various aspects So what we've gone through is custom user groups that it's a very real and strong concept within git lab You just have to know a few little secrets about creating groups that are dedicated and setting a couple settings Those gating controls are used for both code collaboration and deployment control and in many places the custom user groups can be used to do that Also repositories and merge requests can also be used as workflow building blocks So using them above a set of repositories where the repositories are actually components of your workflow rather than kind of the top level concept of your workflow We also enabled de facto development patterns such as microservices Mono repo is one that will be covering in a future session next week actually So you might want to pick that up if you use mono repo instead of the 12 factor type model Also controls by addition and control scope and custom group support So if you're one of the kind of workflow architects, you usually want to know what are all the pieces What context or scope do they apply to and can I use very interesting things like custom user groups in them? So that's what that table is all about is helping you work your way through that So I hope that that's given you a good overview of the richness It's available and some of the ways we can assemble that component tree to suit your workflows And I just like to open it now up to any questions Okay, thanks darwin. And if you have any questions, do you want to enter at this time? You may There's only one current question and that basically darwin was around the code review function. So if you Could share kind of what that looks like being talked a lot about merge requests and things But there's kind of a generic question on code review. Okay. Sure. Sure. Let me See if I can find a suitable sample All right, here's something This is a merge request that's in process So it's a work in progress. So this is going to block that it moves forward But as we look at the single source of truth for change management, we can start to get a view of what's going on So this particular pipeline passed All of our phases passed and if we wanted to we can dig into the individual logs and find out exactly What happened right down to the level of every detail within that particular build step This particular build also for a branch built us a review app So we can open up and see exactly what the app looks like at this level. This is obviously a very simple app But if you had some changes that you wanted to visibly verify you could do so or functionality changes In addition, we can see who our approvals are required from in this case. We just have One group, but we could have multiple groups here. We can view the eligible reprovers find out who has approved We also have roll-ups of any security scanning and license scanning that happened within this workflow So in the phases here, we have multiple security We also have the capabilities of what might be tested. We can have a bunch of sass checks for various Vulnerabilities in your source code. And then if you're using review environments, we can also Check for vulnerabilities in your compiled finished application from the front end And so those all roll up into the security panel And so here we can see all the various vulnerabilities that were found We can take action on those various vulnerabilities Have the capability to break it down by report type So all security scanning comes up as some people sometimes people ask this question They're like, okay, you did a lot scanning, but not only have one security panel Where's the security for individual parts? Well, you can go ahead and break it down that way But because all vulnerabilities are reported very similarly, we assume you just want to see the top level view But you can start to dig into which is which We also have the licenses panel, which was linked from the initial merge request And this allows you to see what licenses are in play And which ones might be blacklisted which ones might be new since the last time the code was compiled And so that license panel is available right here So you could click through from there You have a merge conflict So we know we have to resolve that before moving forward And down here is where you can see what kind of things were going on So this is an audit log for the merge request and you can see what kind of actions were taken Interestingly, if we had some check boxes, this only says closes 137 But if we had a checklist in here as people check the items off, it also appears down here So it's another way to add kind of some approval capabilities Or at least a checklist that must be getting done and you don't really care who does each step And finally down here we see a merge or a review. So someone's saying, hey Here's some I have some concerns about this code and we need to make sure that they get resolved So if there was an ongoing discussion and some code got changed or got justified why it's the way it is Then the person who started the thread could hit resolve thread and that would stop blocking our merge request So all of these controls kind of come together here And we can block merge based on all the different triggers and capabilities that we discussed in our session All right, excellent We don't have any additional questions at this point in time So I'd like to just say, you know, thank you Darwin for a very informative session. Thanks everybody who attended for for joining us We are actually doing a second Webcast coming up next week and that will be on the the use of CICD for More robust pipelines more pipeline visibility and some more complex use scenarios And so feel free to join us then and if you're interested in learning other things further about get lab premium, you can join us And and ping us using the link that you see here on the screen With that, thanks for joining us. We'll be sending over the recording from this webcast in the next few days So keep an eye out for it And enjoy the rest of your day. Thank you very much. Thanks everyone