 Hi, my name is Itzy Ganbaru, technical marketing manager at GitLab, and today I will show you how to integrate continuous testing into GitLab CI Pipeline. Continuous testing helps to deliver applications faster without compromising of quality or security. I will give you a live demo of how you can integrate continuous testing into GitLab CI Pipeline. For this demo, I created a spatial pipeline with a few kind of tests. The first kind is static code scans for security compliance and code quality. The pipeline also will deploy testing environment via its Kubernetes integration, and against this environment, we will run some automations such as accessibility testing, functional testing, and performance testing. All test results will appear in a single place in the merge request. The last thing that I want to show you in this demo is our latest feature related to testing, which is a code coverage visualization, which helps developers and reviewers to identify lines of code, which doesn't have a code coverage. The demo is starting. This is my repository in GitLab. Now I will make a code change into my Java application. Very small change. This is how we do in continuous integration. We push always small changes and create a new branch, and I will commit the code. GitLab creates for me a merge request. I will submit this merge request, and immediately CI Pipeline started. I will click on this link. It will open for me the CI Pipeline. As you see, the pipeline is made of a few stages, and each stage is made of one or more jobs. So first, it will build my code and create a Docker image for it, and we push it into the container registry. The next step, it will run static code scans. First of all, it will check for code quality to make sure my code is readable and meets quality standards. Then it will check for vulnerability in the container. It will also run SAS. It will scan the code and make sure the code doesn't have any known vulnerabilities. And also it will scan my third-party dependencies to make sure that my dependencies doesn't have any vulnerabilities. License scammings will scan all licenses of my dependencies and make sure that we are not bringing into my application unapproved license. Secure detection will scan the code and make sure a developer didn't unintentionally edit any credentials, passwords, keys, or API tokens to the repositories. That can be a big issue, especially if it's an open source project. Another thing is that after this page will pass, GitLab via its Kubernetes integration will deploy for me a testing environment. So I will have immediately live instance of my branch that I will be able to make some automations on that. This is very valuable for me because I can now create automations during my I plan. I don't have to wait for an IT or a QA or anyone to create for me a testing environment. I have a special testing environment only for my branch and it will run accessibility testing. This check will make sure my website is accessible. It will also run a dynamic application security testing. It will check for cost site scripting and other vulnerabilities. The functional testing job triggers a matrix of jobs. In this example, I have a matrix of 12 jobs that will test my application on different OS types and different browser types in each race. And all of those jobs will run in parallel, which will reduce the overall execution time and will provide to the developers feedback sooner. I also added in this example a performance stage and I have here two kinds of performance steps. First is we do a load performance testing on the server. I defined in my test script 100 virtual users that we hit the server and measure the time it took to get the first bytes. And also another test is a browser performance testing that check the browser rendering and the time it took to render the browser. All right, so I see the pipeline completed successfully. So now I can go back to the main request to see all test results. View up shows me a live instance of my application. And below you can see that all of the test results, everything is represented in one place, which is make my life easier. So I don't have to go to other applications and other dashboards in order to see all of those test results. So no changes to the quality browser performance test found even three improved metrics. I can expand and see the improved metrics. However, a lot of performance metrics found one improved in one degree and two degraded metrics. The security scans found one high severity vulnerability. SAS detected no vulnerabilities as well as the dependency scanning. However, the content of scanning detected one high severity vulnerability, which we will need to fix. We can also open the vulnerability and get more details, such as the identifier. We can create an issue with all details. So someone will go and fix that issue. License compliance test detected no new license. You can open the report and see the list of licenses that we are using. But all of them looks good. Means that we don't have any policy against those license. And accessibility scanning detected one issue. I can expand it and see what is the issue. So before I can click the merge, I will want to fix some of the issues that found. So definitely I will want to fix the vulnerability because it's the severity is one, which is high. And after I fix all of those issues, I will be able to click the merge request. Before I merge my code to the master branch, I will assign this merge request to one of my peers. So we will open the code review and make a review of my code. Now I want to show you how I defined all of this CI pipeline. And I will open the .gitlab.ci. This is the CI-CD configuration find in GitLab. As you see, GitLab configuration is done via code, which is great. Developers don't need to rely on DevOps engineer to make changes. This allows developers to adjust this file. For example, if they want to add more tests or make some more deployment for environment, they can easily make this change themselves. So let's see how I defined this find. Here I defined some global variables. Of course, there are no secrets here. Any secret I will not define here I will define environment variables or in the Ashikov world, which has a built-in integration with GitLab. Here I defined the stages and the order of the stages. We have many built-in templates for many common CI-CD tasks. So for example, for built, I didn't have to write the job myself. I just included the built-in template, simple code quality and DAST and browser performance testing. So for the most jobs, I didn't have to write them myself. I just included them from the built-in templates. On some out-of-the-box jobs, I wanted to customize the different templates. So this is example for the deploy testing. This is the job name and this is the stage it belongs to. And here are the scripts that I want that the job will run. And also jobs, we can define artifacts. This will be the output of this job that you will be able even to download after the pipeline completes its run. This is the definition of the metrics functional testing. And you can see here two GitLab keywords. The first is parallel and the second is metrics. And I can define a metrics of environments. So this will create a metrics of tests for all of those combinations. This is the load performance job definition. We execute load performance with open-source tool called K6. I defined this is the job name and I defined some in-appartment variables. Those are parameters that I'm sending to the tool. First of all is a file that contains the URL of the application. And this file I get is an artifact from the previous job, from the deploy testing. Here is, this is the file that we store the URL of my testing environment. And the second parameter that I send is the script name. And it's a folder in the repository. So I can open the repository. And this is the K6 scripts. And here you can see the test definition and the thresholds that I defined for the test. And the URL, which is the parameter that I send from the pipeline to the tool. And the last part of this demo is code coverage visualization. So again, I'm open, merge request for a different project. And if I go to the changes tab, I can see in the right side the changed code. And I see this line. This green line shows me the line that has the code coverage. But here, for those lines for example, I don't have the code coverage. So this as a reviewer, it saves me a lot of time. I don't have to go to JSON files or any other XML files to check which lines doesn't have code coverage. GitHub visualized for me. So now I can go as part of the review and I can write in a message. And always remember to integrate many kinds of tests into your CI CD pipelines. Not only unit tests, but also security and compliance tests, functional and performance to make sure your application is secure, running as it should, and it doesn't introduce any regressions. Hope you enjoyed this demo. See you soon again at my next videos. Bye-bye.