 Hi, my name is Cesar Saavedra, Technical Marketing Manager with GitLab. In this demo, I'd like to take you on what a typical flow would be like for a developer using GitLab. I will be using Amazon EKS as a deployment environment. We have a lot of material, so let's get started. So as a developer, I track my work via boards. Here you can see my three boards open to do undoing. And let's say that there's an application already in production. And it's right here, this is a web app. And as you can see, the spring is here and the background is green. And let's assume that someone would like to make that more customizable. So there is a request that will be created by someone. It could be created from the issues screen right here. Or simply they can just come to my to-do board and enter customize web app landing page. And create and then submit issue. This will create the issue under my to-do board. Notice that the label has been assigned automatically. And I will see this obviously appear on my board. And then I'm going to start working on it. So I'll go ahead and assign it to myself. And then I'll move it to my doing board. Now at this point, I can actually open the issue. And the issue is what the problem is. And the MR, or merge request, is the center of changes of the work that I'm doing and the place where stakeholders collaborate on the resolution of the issue. So here I'm going to say create merge request. Then since I'm starting to work on this, I will go ahead and open web ID and navigate to where the source file is. Let's just say I want to change the background color and I'm going to say AWS. Also, I know that there is a unit test in this project that will test the color of the screen and the string that is being returned. Actually it's going to test what's being returned as the call to that web app. So I have to make the changes here too. So I'm going to commit and I'm going to commit to the branch. Now, if we go back to the MR, now notice here in the MR, you can actually click on changes and see side by side the changes that took place in the files of that project that I applied in this case. This is how the stakeholders on this MR can collaborate down to the source code line changes and say, you know, it looks good to me or something like that. For now I'm not going to put a comment in there, but you know, you can collaborate all the way down to a single source line. And this is good because, you know, through this collaboration, what you get is you get better code quality. It also speeds up the development of features and also increases developer productivity. This next screen, which is the pipeline. So a pipeline has been started as a result of committing the changes to the newly created branch. Since this pipeline will take a few minutes to complete, instead of waiting, I already have the same pipeline already completed. So let's go see it. Here is the pipeline. It's already been run all the way to the end. And this pipeline is part of our auto DevOps pipeline, which comes out of the box and is based on lessons learned and best practices for continuous integration and continuous delivery. These pipelines can jumpstart your development work, saving you time and shortening your development lifecycle. As you can see, they also shift work left as much as possible so that you can identify and fix problems and preempt issues from occurring in production. However, if these pipelines don't quite fit your needs, you can create your own pipeline or modify an existing one. This specific pipeline includes the review app, which is right here. And this spins up its own environment, in this case, in the EKS cluster, so that updates can be validated by the stakeholders of this MR. So let's briefly now go over each of the jobs included in this pipeline. We'll start with a build stage and also the job, which creates a build of the application using an existing Docker file. The resulting Docker file image is pushed to the container registry and tagged with a commit SHA or TAG. Then in the test stage, you have a few jobs here. In general, test analyzes your project to detect a language and framework that is written in or implemented in, and then it runs the appropriate test for your application. It will also use the test you already have in your application. In this case, it will run the single unit test that I showed you earlier. And if there are no tests, it's up to you to add them. Code quality, it runs a static analysis and other code checks on the current code. It creates a report, which is then uploaded as an artifact that you can later download and check out. Container scanning is a vulnerability static analysis for containers to check for potential security issues on Docker images. Gymnasium may have a dependency scanning, runs an analysis on the project dependencies and checks for potential security issues. License scanning searches the project dependencies for their license and checks them for compliance in your project. Secret SAS scans the content of the repository to find API keys, another information that should not be there. Another area related to secrets is the ability to mask and protect variables. GitLab provides this capability via our CICD variable settings, which I will show you in a minute. Spotbugs SAS, which is also part of our static application security testing suite. It runs a static analysis on the current code and checks for potential security issues, for example, buffer overflow. The review app, it actually creates, like I mentioned before, a container and deploys the application on EKS. And the stakeholders actually at this point can review updates to the app before it gets merged into the main branch, improving the fidelity of the solution that will eventually get deployed to production. At this point, I'd like to show you the way to protect variables, sensitive information. So for example, in this case, you can see some variables in this project related to AWS access key, and for example, ECS service and task definitions, et cetera. But if you were to change this, you would just click on these checkboxes. And obviously masking is useful so that you don't show the actual value in any of the jobs or output that is generated from running the jobs. So the ability to protect and mask these variables, shields organizations from potential security issues. So let's go back to where we were here and let's continue going over right here to the next stage is DAST. And that's our dynamic application security testing capabilities. DAST analyzes the current code and checks for potential security issues. For example, cross-site scripting. And then the performance measures the performance of a webpage. It creates a JSON report as well, including the overall performance score for each of the pages. And it uploads this report as an artifact. So let's go back to the MR here. One thing I like to bring up to your attention is that this MR is related to the issue that created it. And when the MR is completed, it will also close the issue. As the jobs run, data is generated and reports are generated that are uploaded as artifacts. You can click on the full report if you wanna get more in-depth information about that specific report. And in here you can, in this specific case is showing you the different types of security issues that it found. And you can actually dismiss the vulnerability. You can create an issue or you can get more information about that specific vulnerability. This specific MR has been, the pipeline ran already. And now we are ready to, it's waiting to be merged. And the assumption here is the stakeholders have had a chance also to run the review environment. So the review environment is actually a running environment that has all the updates applied to it. And it's the point or an environment that the stakeholders can use to check that all the changes that were made are correct. Let's merge the MR. Now notice that the merge button here is not available. It's grayed out. And the reason is that this MR has been marked in draft mode. Okay. So this is something that is built in within GitLab. And it's an extra safety mechanism to prevent an accidental merge and to indicate also that this is still being worked on. So first, we need to clear draft mode by clicking on the markers ready button. And now the prefix draft in the MR title will be gone. And now the merge button is activated. Also, you will see that there is a delete source branch check mark here that is checked. What this will do is it will clean up all the resources used by the review app, including the EKS container that was spun up. This actually helps with container sprawl. Let's merge. And this merge is going to kick off another pipeline that will run all the checks that you saw earlier and it'll take the deployment to a staging environment that will also be running on EKS. By this point, this is gonna take a few minutes. So let's go to an MR that has already completed. So this is the exact same MR that is executed on the other project, but it's already completed. Notice here that the changes were merged into master and the source branch has been deleted and the issue has been closed. So let's go to the pipeline. Now notice here now that this is showing some jobs here that were not there before. And this is basically the continuous delivery portion of the pipeline. You can see here that there is a staging environment. So again, like I mentioned before, once the updates have been merged, an environment is spun up on EKS. And this is called the staging environment. And at this point, you don't see it in this case, but these are manual steps. So these will be grayed out. These actually were grayed out. And you have to manually click on these to do an incremental rollout. You can choose 10, 25, 50 or 100%. An incremental rollout into production reduces the risk and contributes to a better user experience and reduces the danger of an outage. And after the application has been rolled out to production and to the production environment, another performance test is run in production. So let's go back to the completed merged MR. And I wanna click on production here. This is showing the production environment. This list is actually an auditable sequence of changes that have been applied to the production environment. This is the last one that was run. The nice thing about this auditable sequence of changes is that at any point in time, if you introduce a change and you notice that this is showing an unexpected behavior in production, you can always roll back the environment by clicking on this button right here, the rollback environment, which will take you back to a previous known state. At this point, you can click on view deployments and this is actually the application running in production. As you notice, it has a new color that we applied orange and it has the AWS prefix. So the two changes that we introduced into production. The other thing I wanted to show you was the monitoring. We have Prometheus running on the EKS cluster, collecting metrics. And this is showing you metrics, not just for the cluster, but also for the running application here. Let's really deploy this environment and then let's go back to the monitoring window. The rockets that you see here are actually a change that was just rolled out to production. And it's, you can actually see the job itself that executed as a result of that update to production. And the nice thing about these indicators is that they can help you troubleshoot production issues because there's a correlation between the behavior of, for example, total memory here and the introduction of that change. So these demos so far have used EKS and ECS as a deployment platform. However, you can also use GitLab with bare metal and virtualized deployment environments as well as different operating systems like Windows. All right, so to wrap up, we have gone over how GitLab can help organizations speed up their software development and delivery. We discussed auto DevOps and how it can get you started quickly with pipelines that are germane to your project language and deployment environment. Whether it is EKS, ECS, bare metal, virtualized environments or even Windows. Thank you for watching.