 Thank you for joining. Today, we're going to have a mixture of walking through some features, capabilities, kind of a mix of a technical and solution-based Marietta content that will help you think about how to do CI CD different. So with limited time, we will keep it high level for the presentation portion, but we'll walk through some screenshots with a role-play example and then tell you how we do it here at GitLab and have a little demo as well to follow from what my colleague says on it. So this is why we're here, right? We'll do a little intro to set the stage for you. Talk about what I like to call the GitLab advantage and then how we do it. And then the demo portion will follow that. We'll have some time for Q&A, as Megan mentioned. So first, let's do the intro. My name is Parker Ennis. I'm a product marketing manager here at GitLab, and I've been here since about January of 2020. My focus is on CI CD, and you can see my two co-workers down there on the left, Izzy and Leo, that I wanted to say hi, and then Cesar. Hello, everyone. My name is Cesar Cvedra. I'm a senior technical marketing manager here at GitLab. I specialize on CI CD and GitOps. Some details about me right there. I love to watch and play soccer still. I'm a book author and I have three pets, four kids, and a wife. Believe it or not, that's two great hands and a bunny in the same household. It's awesome. Thank you. All right, let's get right into the content. We've got quite a few slides. Some of them will be quick, but we're going to be scooting right through some of these so that we can ensure we have time for the demo and the Q&A. Something I like to call the GitLab advantage. Today, we will be covering a few things, merge requests and issues, auto DevOps built in application security with review apps as well. So let's get into it. First, many of you may be familiar with our model of a complete DevOps platform, but for those that are not, what that means is you get everything you need to deliver more value to your customers faster with GitLab, from end to end, from idea to production. You know, however you want to say, GitLab equips you with what you need to be successful. So you see there on the left some common problems that you and your customers likely put budget behind to solve. So when you see links like this in orange or underlined, when these slides go out, I encourage you to click them. There'll be some links that you can check out after the presentation for more details. And so first, talk about collaboration and how you can improve it. And this focus is going to be on GitLab issues and what we call merge requests. And just to set the stage, collaboration is key, right, to developing great software. And I think it's often underestimated in terms of value. Non-programmers think about, you know, programmers is constantly tapping away like that cat-jiff on their keyboards to code. But you know, in fact, software development is much more collaborative than it is solitary, right? And so it's important to call that out. And I like to always set the stage when we talk about collaboration and some of the features that we'll be talking about here. And so we're going to use a common example here throughout the presentation portion. And it's going to be to new key travel for the sake of continuity. And so for this, we have a modify homepage example. And it'll be familiar as we go through these slides. And our objective will be to do exactly what the the the issue says here, modify our my homepage and add a basic little sign in sign up form. And so if to new key travel is our travel company, and we need to update this homepage because it's missing a sign in form, let's walk through how we set up this process and get lab and start that development workflow in parallel with the collaborative process. Of course, we're assuming now we're logged in and have already been on boarded here for the sake of the example. And what we would do first is is open a GitLab issue. And when we talk about GitLab issues, and we think about software development as a conversation, like I mentioned before, this is the invitation to the conversation, right? And the benefits of this collaboration start at the point of making an issue. So by making an issue, you get your ideas out there early, it allows collaborators to have their say earlier in the process, right? You also notice you've got a title description of what you intend to do. We kept this light for simplicity with the modify homepage. But you could add, you know, whatever you wanted there any relevant information you may need additional context, who's involved requirements, right? You also notice there's a design section. And because design management is weaved into this workflow. So let's let's talk about what we do next, from from that invitation to the conversation and opening an MR, and what merge requests provide. So we've invited everyone right just to give it like a dinner table. And we create that issue and then we'll create the merge request directly in GitLab. It's notable that you can also do this from the command line as well. If that's your preference, and then you can, you know, retroactively link that MR back to your issue. And you might be thinking like, why should I collaborate in a merge request before the work starts, when I can collaborate in an issue, right? Or why create an empty merge request? Because merge requests provide value in a different way, right? Where you're collaborating or communicating as close to the code as possible. That means you can communicate back and forth, make suggestions, comments, all in real time, after you've invited, you know, someone to have a conversation in the issue, essentially like, hey, we started this, now let's create a shared workspace, right? And for for for this example, we could start collaborating with our UX team or our product managers on how to design and implement a basic sign inform as we move along, we could bounce ideas off each other. We can move towards a common goal. And a little difference also notice merge requests are our change requests, you may have heard of them in other areas as a pull request, right? But that happens after the work is done, not before not not before the work is started. So we've got our issue, we've invited the conversation, we've started the work, we've got our merge request, we've got a link. Notice that this is in draft form. So I want to reinforce those first few steps because they're important. The merge request is directly tied to your issue. It can auto close out that issue once you've merged the merge request. So that's something that's been extremely valuable personally to me in my day to day and something that I honestly didn't know I needed until I had it. Another cool thing to note is that when your merge request is in draft form or work in progress, like you see here, now you can make it so that it can't merge until that draft is removed. And so really makes it easier to manage that discussion and keep the flow moving. I also wanted to just quickly show a screenshot of our web ID to write. Most developers have a very strong feeling about IDEs and editors and we work with them all, but sometimes you just want something lightweight that's always there and it just works. And so that's the shout out for the for the web ID. If you're used to seeing things like this and you're more comfortable in this environment, you have that option. I know we're moving quick. Thank you. Also code reviews. I wanted to call out the code reviews and code changes are really, really easy and good lab. You can come and leave comments on each line. You got multi line suggestions and code suggestions that can be applied in a batch, right? All instead of emailing someone, you know, somewhere else with like 12 changes at once or and I want to get across here that everything you've seen on the MR screen is following that initial issue being opened and linked. This is one central location to comment, suggest, use that IDE or static editor and assign stakeholders or feedback and get that, you know, get reviews done. And then also another highlight is merge request reviewers as a feature that we shipped in the past few months. It's really awesome enhancement. It allows you to easily request a review from someone else regardless of where they are or role or team and see the status of that review. And so this is just to sum up the little portion you just saw, right? GetLab lets you initiate that collaboration and conversation earlier. You start with the issue. You've got full visibility across your groups and projects, and it's all in one place so you can easily track and manage those changes. And of course, these will all be available so you can come back and check these out. Let's move on to the next steps. What if we, now what? We've got our issue. We've got our merge request. What if there was no need to write your pipeline from scratch, right? Instead of starting from zero, we could put you on the road with a car and get you to drive where you want. And that's kind of how I like to think of the focus here, which is GetLab AutoDevOps. Essentially what AutoDevOps is is a set of predefined, customizable and extensible CICD templates. And it's pretty unique. We put years of experience and best practices here at GetLab into this, and we're still doing that. So you can see here kind of how this spans and what AutoDevOps can automate for you with just the click of a button or two. And we're going to go right into that. So this is where you configure your AutoDevOps. You let the automation start doing the hard work, right? For our example of Tanuki travel, we're back in that GetLab UI, and you can see that we've toggled away from issues over in the left nav bar, and we've gone to settings to configure our AutoDevOps functionality. All you do here is click one checkbox, set your deployment strategy, and save the changes. You don't have to write your animal based on the template, but you certainly can, right? So it's important to call out that you can customize this. And since we're using a very simple example, we've still, but we still customize AutoDevOps here in our sample CICD pipeline for Tanuki travel. So once you save those changes on the previous screen, you see after the build phase pipeline finishes and AutoDevOps takes over and kicks off the rest of what you see in the pipeline illustration automatically from left to right here. You'll also see this in Cesar's demo. So I'm not going to harp on it, but I wanted to call this out because you will be seeing more of this when he does his demonstration. So Dean, pipeline's done. Now what, right? Now that pipeline is done running, you can see these results and what was done. Everything is interconnected, and that's really important. You get a single application, single location, and you're not switching tabs, you're not switching tools, you're not switching context to find the information that you need. And so some of the things that are important on the screen, you'll see Cesar go over as well and he'll reinforce these with code quality, security scanning, license compliance, etc. Notice that this is our MR and it's still in draft form. And then AutoDevOps why? Okay, you're thinking maybe thinking why? Because you can essentially accomplish what you're seeing in that diagram on the screen with a single commit. And getting CI CD setup and running in your first job, your first pipeline green isn't always easy, but it's crucial and with AutoDevOps it makes it easier. And I kind of like to think that AutoDevOps is like DevOps magic. I love that Jeff had to put it in there. And so next we've talked about the MR, the issues, AutoDevOps. You've got our first green pipeline. And so for our example of Tanuki travel, we've been, we made our code changes. We've been collaborating in the issue in the MR, right? So how do we preview these changes? Moving fast means things change fast. And we want to know exactly the state of our applications, what state of our application is in and be able to easily and quickly, you know, diagnose and understand that. And so if you ever like to think of we've done all this work, how do you know what changed and if it works as expected? So these images should look familiar to you from AutoDevOps. Let's say, you know, we needed to make a last minute change as we were, you know, adding that sign in form. And a colleague committed some changes and you want to preview them before circulating that out for a wider review. Here you can see that the pipeline automatically created a review instance of the application, a review app, and then deployed that up using Kubernetes. So you can validate this in real time, right? It's essentially a staging, a staging environment for every, every kind of change, right? So the bottom right diagram shows that in Mar, we make the changes and then the pipeline runs to apply them. So once that pipeline finishes, you'll see this view app button. You can check out the changes there and verify, validate that those changes are what you want. For a basic example, this is exactly what expected a form added to the original design that you saw in the beginning, that you was just a background picture before, right? With nothing else added. So now you can see that, voila, we can preview and see that we've got a sign in form. And so, you know, I really do think review apps can transform the way you work. I've spent a lot of time working locally, spending up preview, you know, middleman, whatever you're using. And it really does minimize that guess work. And it helps you work more efficiently without waiting on others to review or evaluate your applications. We're talking about saving time. We're talking about utilizing Kubernetes without that steep learning curve. And we're talking about automating that workflow and integrating it with GitLab, right? It's really, really cool. The other thing that review apps are nice for is it helps to make sure you keep your applications secure with dynamic application security testing or DAST. And that's a great transition or a bridge to the next section that we're going to talk about with security and a focus on DAST. And so, I like to say embed security into your workflow, not integrate it. And what does that mean? That means we're integrating it, but we're shifting it all the way left in this contextual, right? It weaves into your DevOps workflow. And so, we'll talk about not just SAS, which is static application security testing, but DAST, because we want to talk about not stopping testing or scanning after you shift to production, right? The tech, you know, we should not, security should not be an afterthought. And we'll be talking about that. So, let's stage it a little bit before we get in. This diagram is what we call our GitLab flow. And what you see there in the middle is an app set, test addition to more clearly kind of iterate that GitLab's approach is scanning code at the point of commit before the code changes ever lead the developer's hands and before those code changes are mingled with others. And I definitely encourage you to check out GitLab flow. We'll be sending you some stuff afterwards. A really, really cool opinionated take on what we think best practices are for you to be most efficient with your workflow. It's powerful. It provides you real-time feedback to the developer and vulnerabilities in your code changes. And that helps you resolve flaws before they are introduced into your main branch or before others get involved or those problems get bigger. And I'm not going to spend a whole lot of time on this slide, but just wanted to iterate that secure, you know, secure scanners run with every commit as part of the CI pipeline to get that earlier detection of vulnerabilities. These are things that you can customize as a part of auto DevOps in your CICD templates to bring it back to the previous section on auto DevOps. And to reiterate what I started with for this section, security needs to be embedded into your workflow in robust, not just integrated. And so really only GitLab can deliver DAST right to the developer alongside all of these other scanner results, all within the CI pipeline, all within your EMAR. I love to link and call back to things. You'll see an example of this merge request presenting this kind of information and says I was demo to follow. And so I'm not going to harp too much on this because you will see this again, but there's a lot of pain that can come when security scans and compliance are later in the process. I think we're seeing a lot of that in the world right now. We've got an executive order and we saw the SolarWinds attack, right? Security is more important than it's ever been. And so let's connect the docs to review apps like I mentioned earlier. So security does not stop or security testing, excuse me, does not stop once the code is shipped. Dynamic scanning requires a functioning application in order to assess that behavior for known vulnerabilities. And so normally this would be done after code changes emerged often in a test environment. But GitLab uses the review app that we talked about earlier to run these gas scans. That means the review app is a fully functioning app that reflects the changes that you make. And this method can provide you clear and actionable feedback straight to your developers about a wide variety of vulnerabilities. And that's before the code ever leaves their hands. Think about that. And this all happens in the review app or you can use DAST against your own, right? Outside against your own. SAST is what I like to think of from the inside out. And DAST is what I like to think of from the outside in. And so I cannot reiterate this part enough. It's all on the merge request screen that you're seeing right here. It's in one place. You're not switching between things. You can tell this is a personal thing with me too, right? And the timing here is really important. This is why I like to harp on it because it's useful for user developer for your developers to fix problems faster. And then just a really quick shout out here to security dashboards. And, you know, these merge requests are great when you see want to see like a discrete change and how that's affecting your app. But you might want higher level view or your direct might want higher level view. Sometimes you want visibility into all the current security issues that are affecting the branch at an aggregate level. And this is a security dashboard that you're seeing here that give you this kind of visibility. Let's you make decisions and prioritize accordingly so that you can focus your remediation efforts in the right place, right? Time is of the essence these days. And that means, you know, what the most important vulnerabilities are instead of how to kind of collate reports across merge requests and try to figure out where everything is and piecemeal it together. It's all in one place. And I think this is especially helpful for security operations and engineering managers. You've got that specific view and GitLab to help you get your job done. And this is just a call out for what we, you know, what we can do in these two areas. And what I like to think of is if shifting left, you know, for our example of Tanuki travel, or, you know, we're making sure that Tanuki travel is secure and we're minimizing risk by shifting, you know, proactively shifting the security scans left, scanning earlier in the process before the code leaves the hands. We're also shifting right and we're making sure that Tanuki travel is safe in production as well. We're looking for those vulnerabilities in a running web application. And we're really focused on being the best solution for cloud native apps to particularly for security. So I encourage you to check out this slide in further detail when it's handed out and check out some of these functionalities, especially if you're more interested in the security realm. And just to really wrap this part up here, not just integrated embedded, right? And I think I mentioned it at the beginning of this, but when I like to think of security with GitLab, it's not just an additional step. It's not an afterthought. It's not something that should be hindering your productivity or your efficiency. It should be woven into your workflow, your DevOps, your DevOps practices. And that allows you to adapt your process to what's going to be most efficient. And what we see this being just a huge advantage more and more as we're growing this part of our product. We've really gone through that, but I think we're right on time for a demo from Sizzar. So handing it over to you, my friend. Thank you. Thank you, Parker. I'm going to go ahead and share my screen at this point. You should be seeing a screen with two screens side by side. Yep, we see it. Okay, good. So what I've done here is some of the pipelines take a few minutes to run. So what I've done is I pre-recorded the demo. I do have the project up and running for the Q&A section. So if you have a specific question about the environment, we can go to the project and we can look in there. So in this scenario, we have two developers. Two developers. One of them is Sasha and that's the left side of the screen. On the right side of the screen, we have another one, another developer called Sizzar, which happens to be me. So there is already an application running in production and let's go see it because there will be a change happening, an update to the application in this demo. So there's a production environment running for pods in Kubernetes and the Kubernetes cluster. So let's log in to the production environment and I want you to notice that this is an inventory program with products in there. But I want you to notice that the background is all purple for the three different screens to edit products, delete them and create new products. So let's log out and there's also another environment called staging and there's one pod only in that environment and let's log in onto that application running in staging that's Mickey. And again, you can see the same application running in staging where the background is purple. So let's close that and now let's just say that Sasha would like to make a modification or request a modification to update the application. She doesn't like the purple background. She would like that background to be orange. It's a simple change. So she's going to go ahead and create an issue. She knows that Sessor is going to be working on this so he's a developer assigned to this application. So she's going to assign it to Sessor and then Sessor is going to see that in his board and he's going to switch it to the to-do board and then he's going to start working on it. So he moves it to the doing board and he's going to go ahead and create a merge request. When he creates a merge request the merge request gets automatically associated with the issue. He's going to make Sasha the reviewer of his work of the updates because she was the original requester. So she's there as a reviewer. He's going to go ahead and open the Web IDE and start making changes to the application. So he goes to the three different templates that show that purple background and he's modified he's going to modify that to orange. So there are three files three screens. So he's going to make the changes to those three screens and then he's going to commit the changes. That's going to be deployed to a feature branch. Not to the main branch. So when he commits. So now what's going to happen is the this is going to instantiate or start running a pipeline which is the review pipeline. So this review pipeline consists of many stages and jobs as you can see here. The first one is the build job. The job is going to be built and an image is going to be generated here and stored in the built in container repository within get lab. Then the test stage has a variety of jobs called once called quality right there that checks the coding standards within the Java code. There's a container scanning check security vulnerabilities in the containers. Yes, lint is going to check the JavaScript portion of the application. The next one is gymnasium Maven. The Maven build there's going to be a license scanning job. Make sure if you know everything's okay with the open source licenses. There's two more that I missed. Sorry, we can come back a little later. There's also a review stage which we'll show you in a minute. That's the performance in another job that will bring everything down or clean up the environment. So let's go into the review environment or job. And this actually is a way you can get to the instantiated environment for review. That's one way to get to it by clicking on that URL. The other way, sorry, let's move on to the DAST. So once the review environment is up and running, the dynamic application security testing tests are run against it. There's a variety of tests that are performed. A lot of them are from OWASP tests. And as you can see, there is pages are checked, cookies are checked, etc. And they're all going against that running application in the review environment. This review environment is an ephemeral environment that will go away after the review is done. And the purpose is that the stakeholders of this that are participated in this modification can actually see the running application before it gets before it even gets merged to the production environment. Here we're checking the job that does the performance testing. So this is checking for the rendering of the web pages and the speed. The we use an open open source project site speed IO. And and then. Okay. So remember, Sasha had been made a reviewer. So Sasha, because she was made a reviewer, she's going to see a to-do list entry in her to-do list. So she's going to go ahead and click on the MR in that message and go to the MR to the merge request. Now that you can see now the collaboration in motion here. So she's going to go ahead and check the changes that Cesar made. So she's going through the code and everything looks good to her. She's making sure that, you know, notices there are three changes for the three different files that got modified. Also, one more thing that she notices is there's a bunch of artifacts attached to the MR with the result of the test. So first one is the browser performance test. Remember the performance of the rendering of the pages. Rather, she can expand that and see some of the metrics as a result of those tests. Same thing with security if she goes to check the few the full report. There is all the security vulnerabilities that were detected as a result of the tests. At this moment, she could dismiss the vulnerability. She could create an issue to be addressed later on. If she wants to understand the vulnerability better, she could click on the view more info. And when she clicks on the view more info, she can see a lot more information about the specific vulnerability. Very good. So let's cancel that. And let's go back to the MR. As you can see, there are more artifacts in there, including license compliance. So let's check the view full report. There are no license issues found, but this is super important, especially nowadays when many projects use open source projects or many applications use open source projects. You don't want to run into an issue where you're violating the license of an open source project. All right. So now that Sasha has reviewed everything, she says she communicates via the MR to Cesar and says changes look good to me. At this point, she could also view the app by that, by that this button here, this is view app, but she chooses not to at this moment. So now Cesar gets the message from Sasha. She sees that she's told them everything looks good. So now let's check the, excuse me, remember that ephemeral review environment that it's up and running with the modified application. So let's go look at it. Let's look in as Pluto. And as you can see, the application here has the orange background isn't have the purple background that in production, that it's in production. Remember, this is running in the ephemeral environment review environment. This is part of the review apps that Parker mentioned earlier. And as you can see here, we're checking production. And in production, you see the old or the application without the changes and the same thing in stage. And you will see the application with the purple. The reason is that the changes have not been merged to the mainline. That's another way to get to the review app by using that button called view app from the MR itself, which is a simpler way instead of going to the environments page. Good. So now that everything is okay, let's mark the MR as ready. It's no longer in draft mode. That indicates that all the reviews are finished. And now let's click on the merge to merge the changes, merge button to merge the changes to the mainline. Now what I show you here quickly that the stop review job is kicked off automatically when you do the merge and it's cleaning up all the the review environment. It's closing the MR, closing also the issue for you. And as part of the merge, a new pipeline will be spawned and this is a new pipeline. This is actually the pipeline that is going to deploy the application with the changes that have been already merged to production. There's also a staging environment there. A lot of these tests that you already saw like dynamic application security testing will be rerun. All the static tests will also be rerun. And then the production deployment will be a manual incremental rollout. The performance test will also be run one more time. Very good. Now the review environment there, it actually what it does is brings up an environment so that the dynamic application security test can be run on that environment. Okay. And it's also an ephemeral environment that is brought down at the very end of the deployment. Very good. So now that remember the review apps has cleaned up the review environments and as you can see it's already gone so you will not have any container sprawl this way. And now that the the CI CD pipeline here to production is all the way has completed all the way to staging. So the stage the application has already been deployed to staging. And now we can manually deploy to production and let's do it at 50%. The idea is that once you have it in staging you can check the application if everything looks good you're happy you can deploy to production. Here 50% is indicated by the two out of the four nodes there have the new application and two don't they still have the purple background. So now let's go ahead and roll out to 100% to production. And now the four nodes there or pods will just turn to green indicating that all of them have the same application at this moment which is the one with the updates. You can check the application by clicking on the open live environment button and let's see in production there you go that's the application with the updates now in production and also it should be in staging. There you go. So staging also has the updated application like we expect expected. Okay. So if we click on the monitoring button there these are metrics for the production environment for the entire cluster. You can see total memory total course those little rockets indicate the commit the last commit that just happened and this is super useful because if there are any issues if you detect any discrepancies or misbehavior after you made a deployment you can correlate that misbehavior or that anomaly to specific deployment that you apply to production. There is a memory usage metrics. There's also core usage per pod and other metrics even for the nginx ingress. This is sole metrics for the Kubernetes cluster on which the application is currently running. You can select the environment if you want to see metrics for a different environment for example staging so and if you change that you'll see the metrics that are being collected for staging and they look similar to the ones for the production environment. Very good. So let's go back to production and one more thing you can do here is you can drill down to seeing metrics of a specific pod in a Kubernetes cluster and you do this by selecting Kubernetes pod health and then you select the pod name from the select a value pop down and there's a bunch of pods there that are running applications to support the cluster and the deployment of GitLab application so that cluster. So we need to find a pod that is actually running the application we deployed and that happens to be one that is starts with the word production dash. So we just select one and you will see the metrics for that specific pod in your in your cluster. Briefly there you saw the little rocket if you just position the cursor in the right spot you will see the commits associated to that specific deployment. There you go. So again again you can correlate an anomaly in production after deployment to specific deployment if you see a discrepancy there. All right so let's go back to Sasha and refresh the screen and you see that the MR has been merged and and again you know as when the MR was merged the issue was automatically closed. So if she goes to the closed issues she will see that the issue that she originally created is now in the closed state. And one more thing is that you can see that when the MR was created there's also a link between the issue and the MR it says related MRs there so that relationship is kept as part of the issue also. So it's you know you see the relationship from the issue to the MR and from the MR to the issue. Very good. So that's all I had for this demo. So I'll turn it back to you. Awesome. Or Megan, sorry. Yes. So we have a few questions in the Q&A function and just a reminder feel free to keep dropping those in. I'll go through them. If you would like to verbalize your question follow up on your question or we didn't quite answer it feel free to raise your hand as well and I can unmute you so you can ask your question. It looks like the first one is do you offer an on-premises option to run GitLab? Parker says I'm not sure who wants to take that one. Yes on-premise SAS or hybrid those are options that you can do. Perfect. The next one is what is the difference between an MR and a PR? Great one. So yeah let's start in a little bit but a pull request PR is typically open after you've done all the work, right? Think of it kind of like we've made our changes maybe a bunch of developers working on their own branches and then you're going to open that PR after after you've done that work with a merge request you're going to open it. I'm at the inception of that idea or before the work is started is the easiest way to put it. Yeah if I may add something there before joining GitLab I use GitHub and the difference and a lot of there are a lot of open source projects that use GitHub and the main difference is that in a PR as Parker mentioned a lot of the work and the collaboration happens in the issue in GitHub whereas in our and then you pull the PR when you're ready to make the changes and whereas in our case the issue just describes the problem but then really the MR is with all the collaboration happens and the reason is that we encourage that and our GitLab flow encourages that because of their review apps capability because of that automatic ephemeral review environment that is brought up for you that all the stakeholders can't collaborate on right so you can actually see the running application as you as you saw in the demo with the updates and this is way this is before any of the updates are actually merged to the main line so that's what most of the work is done within the MR with GitLab great it looks like we have a question from Edgar if you would like to go ahead and verbalize hi I was thinking that how long can we have those viewers artifacts available after a deployment and to production let's say that for example we deploy today maybe 10 futures and then after that maybe a week three other merge requests were deployed also right but somebody create a bug for for some futures that it suppose we deploy today so how can is there a way that we have available those app viewers artifacts and then we can check over there if we really deploy I mean I don't want to go back and then download the commit code and then perform test because you show that there is a way right that where we can test where we were deploying right so is the question is how long can the artifacts stick around how long do they stick around the viewer the viewer for that though the review app how long is that how long is that environment stay yeah yes so okay so their their review the ephemeral environment let me show you actually I don't think I have a review review let me share my screen real quick there's a default value right says all right believe it's what 30 days and then if you just perform another commit right no matter how small it is or go into that actual pipeline and read you know rerun that part of the job either one of those would accomplish spinning back up that ephemeral environment right so one thing I want to show you is that the ephemeral environment remember I show you the review the review pipeline and the last job was to bring everything down yes you can actually choose not to execute that okay you can tell githlab don't in fact when you do the merge you can say don't delete my ephemeral environment it's a checkbox yes that's what I was looking yes and if you check that the review environment will stay around but yeah but remember that is that gonna cost me more I mean well yeah well it'll cost you more in the sense that is what do you mean cost you more I mean I know that I'm not familiar with these ephemeral environments I don't know I hadn't implemented yet so I don't know if to the company will cost me more by keeping those artifacts over there right if you have a if you have a githlab subscription I think it's included in your subscription the that's a very good question actually I don't I mean if you're paying a githlab subscription you have the option of leaving this review app running I don't see how that would affect your subscription Parker do you know I mean I think it's more about resources right I mean naturally the longer the longer any any environment the more it's going to cost but I think that depends on how large you know what kind of environment it is how large the work you know what kind of work it's doing like for instance I think what is we have a number on our average cost I can't recall it off the top of my head per pipeline but yeah essentially you know the longer environments up you obviously have to pay for those resources but the review app there's a question there it is utilizing Kubernetes correct says out for for the review apps spinning up so so two things real quick so Edgar when you when you choose not to delete the ephemeral review environment whenever you get ready to delete it in the future the easiest way to do it is to come back here and just click on stop review and it'll clean it up for you oh okay yeah the other question was the one Parker you just asked me can you ask me any other questions yeah it was just Pawan I hope I said that correct in in chat so the review app runs on vm or on a cloud platform or something like that where do you run in a GitLab environment right so review review apps the way you've seen it here is part of auto devops and we have what we call the the portion of auto devops that does the deployment is called the auto deploy templates and we have auto deploy templates for Kubernetes which is what you've seen here we also have auto deploy templates for ECS and EC2 so that's what I wanted to add there awesome perfect I know we are at time are there any last questions that we want to squeeze in before we depart yeah I have an extra one uh Paul I think you were mentioning that I can rerun the pipeline right and then use a void to deploy but is that going to also have the option to go to the ephemeral environment without deploying so the the um in what you saw let me share my screen again in what you saw there is you saw the auto devops pipeline so in there there was a staging environment which only had one node running and then a production environment which had four nodes so you can choose so the way we define auto devops or configure was through here CICD expand here so the way we configured here is we decided we select this third strategy which is which is is saying build the application run all the tests and then deploy to the staging environment environment which happened to have only one if I can see it let me see the the environments okay here it is so so what what is doing basically the this strategy is going to deploy to staging and then stop and then at that moment you can log on to staging check the application if you want make sure everything is working fine and then at that moment you have the option to manually deploy to production incrementally okay so that's what this strategy says you can choose yeah if you can choose to deploy 10% and then try the application in production and make sure you hit one of the new applications and make sure that it works okay and if you feel comfortable then you can incrementally deploy to 25% little by little right and then when you feel fully comfortable that everything's fine then you can deploy to 100% and then you you will have the updates in staging and also in 100% of production yeah I I think I didn't explain properly yeah please explain it so we already have three pipelines right that run I mean in the history so I mean if I want to go back to the older pipeline that was run I'm able to use stop on the certain point you mean start yeah I mean start and then stop right because I don't want the deployment to be completed I just want to test that everything was correct you can go to a pipeline that that has a manual step that is a past pipeline and execute that okay yes you can okay thank you great questions awesome thank you so much for everyone for taking the time out of your day to join