 We are celebrating the release of GitLab 14. My name is William and today I will introduce one of the new features included in this important release. Let's talk about code quality. In the past, when authoring or reviewing a merge request, if you wanted to know the impact of your code changes in the quality of the project, you needed two windows open, one on the code diff of the merge request and one in the main merge request page to see code quality changes. This back and forth is inefficient. How are we solving this problem? To solve this problem in GitLab 14, let's consider this scenario. I am a developer working on a merge request. I added some code changes. This function looks a bit inefficient, but please don't judge me. Let's see what the code quality job tells us. All right, I'm done. I commit the changes and all is good. My commit will start a new pipeline. Here, in the merge request page, I can see the changes I commit. Yes, this is the function that I just added. All right, let's go back. And when the pipeline has passed and finished, I can go back to the changes tab and what is this? Well, it seems that I have introduced a code quality violation and I can see the exact line where it happened, along with a description right in the diff view. Cool. Although I introduce a code violation, this is a good thing because now this feature will allow me to quickly identify critical issues before merging any changes. From here, I can review the code, submit the review and avoid the back and forth between windows from the past. If you want to learn more, follow this QR code. Stay tuned and let's continue learning at GitLab.