 Hello, this is Dan Gordon, Technical Product Marketing at GitLab. I'm going to give you an overview of GitLab and how it can help your organization develop and deliver software better. We're looking at a group page on GitLab and this group has a new project in it. Let's take a closer look. As you can see, the Kubernetes configuration has already been done and so has the AutoDevOps or CICD configuration. By simplifying the configuration, GitLab empowers your teams to set up Kubernetes clusters for their own projects. The same is true for setting up and running an entire DevOps pipeline. With those set, let's get working with some code and go to the repository files. GitLab has already started a pipeline to run and test it. We'll dig into the pipeline details later, but for now it's great to know that with minimal effort, we've got a fully functional CICD pipeline up and running. Now, evidence shows us that when it comes to software creation and delivery, high-performing teams collaborate on their work. A collaboration best practice is to capture and track the work with what GitLab calls an issue. Others call it a ticket or a work item. We do this so that others can asynchronously collaborate. So, let's go to the issue boards to start. Boards help us to plan and organize our work. Lists are fully customizable and you can have multiple issue boards per project to help your teams organize their releases. Let's get started on this issue. First, I'll move it to the doing list and this will update everyone that it's being worked on. Notice that the labels automatically updated and so did the totals for the tickets in the list. This helps your teams to be aware of the work that everyone is taking on. Now, I'm ready to start working on the issue so I can jump right into it. The issue is for collaboration on the problem definition. It captures what we need to solve for. On the other hand, a merge request is how we collaborate around the solution to the problem. Once I understand the problem to solve, I'm ready to start working on the solution. I can ask GitLab to create a merge request. When the MR is set up, GitLab automatically creates a new branch for me to work in and it starts it with the issue number to keep them associated. It also automatically closes the associated issue when it's completed. The MR holds discussions, commits, and changes. It will also be the consolidation point for tracking pipelines, test results, and links to review apps, which we'll cover in a minute. To make edits, let's go ahead and use the web IDE. The web IDE is a convenient development environment, all in my browser, with no need for additional configuration or setup, and it is all part of GitLab. Let's do a quick file edit here. When I go to commit the changes, I'll be shown the diffs on them, which is handy to make sure that I am ready to commit. I'll stage my changes, add a short message, and then commit the changes back to the same branch. After the commit, GitLab automatically kicks off the CI CD pipeline that will build, test, and deliver our code. You're seeing the features we call AutoDevOps in action. I can customize the AutoDevOps pipeline or define my entirely-owned pipeline if AutoDevOps isn't right for me. Let's go take a look at the pipeline that got kicked off. Look at all the things that this pipeline is doing for us. Remember, this was set up automatically. We didn't configure any of this. So let's look a little closer at what it's doing. The build job uses our Docker build file, or if that doesn't exist, Heroku build packs to determine the language of our code and how to build it. During the build stage, it will build the code, then build a Docker image to run it in, putting the resulting image into the GitLab built-in container registry. Code quality runs static analysis on your code to look for stylistic and other quality problems. Container scanning looks for vulnerabilities in the containers that make up your application environments. Dependency scanning looks for vulnerabilities in all your applications' dependencies. License management looks at all the software licenses associated with your software's dependencies to make sure that you are not inadvertently accepting a software license that goes against the policy of your organization, such as accepting a viral OSS license that makes your code free. Static application security testing looks at all your code and checks it for known code vulnerability patterns, such as buffer overflows. And test runs the language-specific tests your organization has defined, such as for unit tests, functional tests, etc. Now, the review app. Here, GitLab spins up an ephemeral instance of your code before it is checked into master, running as a live application that can be reached online so you and your stakeholders can see and interact with the application with your most recent changes. This ability is game-changing for early validation of changes. And because we now have a running application, we can now do dynamic application security testing, where GitLab scans the running app for vulnerabilities that only appear in a running app, such as cross-site scripting vulnerabilities. And also because we have a running app, we can do some testing for browser performance to see if our code changes have affected the user experience, but to see the real beauty of the review app and all this automated testing, let's go back to our merge request. So we can see that the merge request has been updated with lots of information about our changes. Here we see a new line showing us that our app was deployed to a review environment, and here's the link to actually see our changes running live. That's definitely orange. And security scanning detected no new vulnerabilities, but we can look at the full report. And when we do that, we can see all the vulnerabilities that security scanning has found in our application. For each vulnerability, we can get more information. And I can even go to the vulnerable spot in the file. I can dismiss this vulnerability, in which case I won't be alerted about it again for this project, or I can create an issue to resolve it. Now, back in the MR, we also get the license scan report. If there were new licenses or licenses against our policy, they also would be flagged in the MR right here. Let's take a look at that report. From here, we can see the details about all the licenses that our license scanning found. We can get more details about each of the licenses. And with the proper permissions, we can blacklist the licenses so that they will be flagged from now on, or we can approve them. At this point, we'd usually ask for another team member to review our merge request. They can see the exact code that has changed and even comment on it. And we'd see a thread of the discussion so that everybody else is able to follow along. Now, this all looks great. So let's merge the changes into the master branch. So now we have a new pipeline that's been kicked off, merging to master. And inside the pipeline, it looks familiar, but a little bit different. Instead of creating a review app, this one is deploying to staging. And then we'll wait for someone to release it into production. So let's go take a look at our environments. We can see what is running in each environment. Here we can see that production still has the older code, which makes sense since we haven't released it yet. But if we look at the staging environment, we can see our changes. When we're ready to deploy into production, we have the option to roll it out incrementally. That doesn't make sense with only one instance running in production. So let's scale that up first. I'll just add this variable and we'll set that to 4. Then we'll go back to our environments and I'll redeploy my production environment. And the deploy board should show its scale in real time as the fleet rolls out. There we go. Now, let's incrementally roll out our code changes to production. We'll do 25% at first. This way, some of our pods in production will have the new code and are taking a portion of the production traffic. The rest of the pods are still running the old code. This is a great way to reduce risks in the deployment. There we go. Once we've validated that the new code is working as expected, we can then go ahead and ship it completely to production. Let's go ahead and do that now. Great. Now our new code is in 100% of production. So that's the high level status of your deployment. But what about monitoring the ongoing health of your applications? Well, clicking on this monitoring icon leads us to the graphs where auto monitoring is showing us the performance of our production application. I can see the Kubernetes system metrics for CPU utilization and memory usage. But we also get response metrics, HTTP error rate and latency and throughput. And all of this is taken from the built-in Prometheus monitoring, the leading open source monitoring solution. So you can monitor how your app is doing. There's also lines for each deployment. So you can correlate changes in performance caused by recent deployments. Application performance monitoring can help your team be more strategic, preventing errors versus simply reacting to them. Imagine if your application monitoring tool could help you avoid pushing poor performing code in the first place, saving your business future downstream costs. So that's it. We took a change through the complete DevOps lifecycle using the only complete DevOps platform as a single application. Welcome to GitLab, helping you bring modern applications from planning to monitoring quickly, securely and reliably.