 Hi. I'd like to take you on what a typical flow would be like for a developer using GitLab. I will be using EKS as a deployment environment for the first part of this demonstration. We'll also make a quick reference to our recent integration with ECS. I would like to then show you behind the scenes on how everything works and integrates together. And finally, I'd like to spend a few minutes showing you how to use GitLab to manage infrastructure's code, specifically what is known as GitOps. 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 is 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 and for our friends at AWS. 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. Can double click on it. 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. I'll also create a branch. And then since I'm starting to work on this, I will go ahead and open WebID. And in here I'm going to go ahead and navigate to where the source file is. And let's just say I want to change to make it more a customized version for our friends at AWS. I'm going to change the background color. And I'm going to say AWS. And then 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. There you go. 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 by providing comments. So for example, you know, if somebody would like to add a comment to this change, they can actually make a comment right here 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. All right, so let's go to the, to 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. All right, so 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. So let's go down to each of the jobs here, code quality. It runs 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 Maven 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 and other 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. SpotBug's 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. This is our integration to 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. We are on our way to doing the same integration with ECS. Let me show you real quick what we have for that. So this is the pipeline that deploys to ECS. As you can see, it's our first iteration. The pipeline is really simple. It's just to build and then deploy. And we are, as I mentioned in our first iteration of this work, and we will be adding more functionality as we iterate more and more on this implementation. So 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, etc. And you can protect them and mask them by checking. During the creation, or actually you can edit one, for example, let's do this one. This is not protectors or masks, but if you were to change this, you would just click on these checkboxes. And, obviously, masking them 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. The DAST analyzes the current code and checks for potential security issues, for example, you know, cross-site scripting. And then the performance is called or it uses the auto browser performance testing. That's the name for it, the complete name. And what it does, it measures the performance of a web page. It creates JSON report as well, including the overall performance score for each of the pages. And it uploads this report as an artifact. All right, so let's go back to the MR here. And this is the MR. All right, so 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. Okay, so let's say at this point, I mentioned before that all the, you know, as the jobs run data is generated and art and reports are generated that are uploaded as artifacts. And on this screen, you can actually see the results of a lot of the jobs, the jobs generated. In this case, I'd like to, for example, if you expand here, the security vulnerability security scanning, I'm sorry, you'll see a bunch of, you know, the results for each of the tests related to security. Here you can click on the full report. If you want to get more in depth information about that specific report, and in here you can, you know, in this specific case is showing you the different types of security issues that you found. And you can actually dismiss the vulnerability vulnerability, you can create an issue, or you can get more information about that specific vulnerability. All right, so let's at this point, this, this specific MR has been the pipeline ran already. And now we are ready to is waiting to be merged at the assumption here is the stakeholders have had a chance also to to run the the environment. In fact, if we go here. This is the review environment. So if we go to, to the review environment, we should be able to see the deployment, which you have the changes here, see. So the review environment is actually a running environment that has all the updates applied to it. And it's the point or environment that the stakeholders can use to check that all the changes that were made are correct, basically. So let's see. So let's, let's merge the, the, the MR notice that the merge button here is not is not available. It's great out and the reason is that this MR has been marked as a working process. Okay, so this is something that is built in within GitLab. And as, you know, to prevent someone for, you know, it's an extra safety mechanism to prevent an accidental merge. And to indicate also that this is still being worked on that don't merge it yet is working progress. So people are working on it are reviewing it. So don't merge it. So first, we need to clear the whip status and we do that by resolving the whip status here. And now the whip is gone from the title. 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. So you won't be left with EKS, you know, environments running and idle. So this cleans up after, after, you know, cleans up all the resources basically after the merge takes place. So let's see. So let's, let's merge. And this merge is going to kick off another pipeline that will basically run, you know, all the checks that you saw earlier, and it'll take the, the, it'll take the deployment to a staging environment that will also be running on EKS. So let's go at this point, this is going to take a few minutes. So let's go back to, let's go to an MR that has already completed. And that is over here. Let's go here. It is this one here. So this is the exact same MR that is executed on the other project, but it's already, it's already completed. Okay, so let's, let's go to the pipeline so you can see it. It's this one here. Notice here that, you know, 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 you the, there is showing some jobs here that were not there before. And this is basically the, the CD portion of the pipeline, the continuous delivery portion of the pipeline. You can see here that there is a staging environment. So again, like I mentioned before, all the, 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 this 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, 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 into the production environment, another performance test is run in production. So let's go back to the completed merged MR. And I want to click on production here. All right, so this is showing the production environment. This is, this list is actually an auditable sequence of changes that have been applied to the production environment. And 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 shown in an expected 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 introduced into production. The other thing I wanted to show you was the monitoring over here. So let's go back to production. Sorry, I shouldn't have closed that window. So I'll show you the deployment. So now let's click on monitoring. And we have Prometheus running on the EKS cluster collecting, collecting metrics. And this is showing you metrics, not just for the cluster, but also for the running application here. And one thing I'd like to show you is let's go back and let's really deploy this environment. And then let's go back to the monitoring window. And what you will see here now is this symbol here, this little rocket here. Let's change it to actually 30 minutes actually. And the rockets that you see here are actually a change that was just rolled out to production. And 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 let's say you apply a change and you see that memory is going out of whack. Then you can actually, from looking at the graph, you can see, oh, that change was highly likely that that change caused that issue in production, that much higher consumption of memory. And again, like I mentioned, this helps you troubleshoot production issues faster. So these demos so far have used EKS and ECS as a deployment platform. So however, you can also use GitLab with bare metal and virtualize deployment environments as well as different operating systems like Windows. I'd like to show you a peek behind the scenes of how easy it is to create projects and work with pipelines. So for that, I'd like to take you to my GitLab dashboard here. These are all my projects. And to create a new project, you can create a new project, click on new project here. And here at the top, you can say create from template and it's a variety of different templates here that will help you, you know, we get you easily jumpstarted on your development effort. So we've been using the spring one here that what you've been seeing the spring project that you've been seeing came from this template. So you can use that template. Now also, you could import a project from GitHub. So, you know, this allows you for the easy migration of your projects to GitLab. And you know, and you could also integrate GitLab CI CD with GitLab, for example, you can do that from here. You can import projects as you can see from other repositories as well. All right, so let's go back to create from template, we're going to select the spring template. And let's just call it crack for step one, I think that's what I called it. Now this point that you can select it to be private or public project. In this case, we, you know, we can leave it as private. And once you create project, it'll create a brand new project that will look like this right here, right here. This was actually populated. I'm not going to press on create, because I really did a little, it'll reject it because the project that project name is already taken. But this is basically once you click create, this, this is what you will get. It populates your project with sample code that we saw before. And at this point, what you can do is you can start creating a new pipeline for this project. Okay, so let's create that. So you would say here plus, and you say new file. And in this case, let's do a GitLab CI YAML. And again, you can choose from a variety of templates for pipelines here for different languages and different frameworks. But in this case, I like to, I like to pick the sample pipeline or template pipeline for auto DevOps, which is what you've been seeing. All those, the pipelines that you've been seeing so far are based or were the, the auto DevOps pipeline, which is this one here. For example, the stages you were seeing graphically earlier are listed right here. Build, test, deploy, review, et cetera, including the incremental production, rollout to production, et cetera, they're all here. So you can start with this pipeline if you want. You can modify it if you want, but even if a template doesn't fit your needs, you can create your own. To modify this one, for example, there is some instructions here. But if let's say you don't want tests, you want to disable the tests in your pipeline so that they can run faster. You can just copy that and paste it here in the variable section here of the of the CI YAML file. And they would just say you said that to true. And if you said that to true, then it will disable all the tests related jobs in this pipeline. So just like GitLab helps organizations speed up the development and delivery of their applications. You can also do the same for their infrastructure. So let's discuss here GitOps. So infrastructure as code is a discipline of using Git or GitOps. It's a discipline of using Git as the main source of truth for managing your infrastructure as code. Where, for example, the YAML files defining your infrastructure are like the source files in an application. In this group, you can see two subgroups. One for the applications, which is apps, and one for the infrastructure as code. There's a nice separation of roles and concerns between development and operations, which optimizes the work and collaboration among teams. In addition, GitLab granular role-based permissions helps to accomplish this in a safe and controlled manner. So let's go to the infra subgroup here. There is a project called AWS. And this project right here contains files that describe your infrastructure as code. So we're using in this case Terraform. And for example, we can review some of these. The vpc.tc describes your network using a Terraform file here. And this specifies in the number of subnets you're going to have and what they're going to be. And it's using the module vpc here. Let's see, for example, the EKS Terraform file. It actually is the Amazon EKS configuration for the cluster. Here, for example, we're specifying that that's going to be the instance type, CPU type. You can select from a variety of instance types from Amazon here. And also it's going to be starting a number of nodes of five for that specific cluster. And we're using the module EKS there in here. Then other files, for example, the backend.tf is the state file location configuration. The GitLab admin Terraform, it adds the Kubernetes service account and the group cluster tf. It registers Kubernetes cluster to GitLab group, for example. So to show you the running application, we can go to the apps here. And again, if we go to this project, this is again the same project that we've been covering through this demo. This is the JavaScript project using the template. If we go to operations and environments, we can click on production. And here you can see the application is running with all the changes that we applied through the MR. Now this project is a separate project, but it's applying the GitOps concepts to the way the groups and subgroups have been organized. 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, Bermedal, virtualized environments, or even Windows. We went over how easy it is to create a project and create and modify a pipeline. And lastly, we covered how GitLab can help you in managing your infrastructure scope. Lastly, GitLab is a complete DevOps platform delivered as a single application, fundamentally changing the way development, security, and ops teams collaborate. GitLab helps teams accelerate software delivery from weeks to minutes, reduce development costs, and reduce the risk of application vulnerabilities while increasing developer productivity. Thank you so much.