 GitLab is the open DevOps platform, changing how you deliver software. Whether you are working solo on a small team or for a large enterprise, our single application is scales with you to provide unparalleled collaboration, security, and development velocity. Let's take a closer look on how GitLab helps team collaborate, iterate, and deliver results that serve customers and business needs. Aery, a VP of app development, notices a downturn on subscriber growth. Concerned with the impact this could have on the business, Aery communicates this to the team by uploading a screenshot of the problem metric on their business general channel. From this very same channel, they can automatically trigger the creation of issues in GitLab. In this case, this third-party application is integrated using webhooks configuration. So, as we can see here, by sending a message with this command in the business general channel, Aeryn created an issue on GitLab. Cool. From here, the team can take it and start collaborating and troubleshooting this issue and find out why the subscriber metric is going down. Parker uploads the screenshot to the GitLab issue and tags Delany, the dev team lead, who will use GitLab metrics on their operations. On their operations, we can check some metrics of the Kubernetes cluster where the application is deployed. Check in this way some standard metrics such as CPU, memory, network, and so on. Everything seems fine. So, Delany goes back to the issue and concludes that it's not the infrastructure fault. Delany suggests that the drop in subscribers could be caused by recent changes to the application front. Thus, reminding Parker of another issue about navigation problems is the mobile version of the app. Parker links the mobile website recent issue to the subscriptions metrics one and brings Presley the designer into the conversation. Linking issues helps the team to create associations between them while troubleshooting the problem. Presley tries the website on different window sizes and yes, the problem is in the front. The subscribe button is unreachable on mobile. Presley uses the issue boards and gives priority to the mobile website one. All right, Presley works on the design using Figma. Designers can upload their work directly to GitLab issues. Here, we right click on the design and select the corresponding issue where all the conversation has been happening. Click on Upload and that's all it takes to send it to GitLab and start handoff conversations over designs and code. The mobile redesign is ready. Coding time is about to start so they tag Sasha, the developer. Because everyone has access to the same information, team silos are broken down. Discussion about the design happens in the GitLab issue and when Sasha is ready to code, she creates a merge request and by using the Web IDE, she's ready to start adding the corresponding lines of code that will improve the website responsiveness. All right, the changes to the style are added. She's ready to commit. Here, we can see the diff in the code and once she adds a meaningful commit message, we are ready to commit to this branch. This commit triggers our continuous integration pipeline. Where the code Sasha just added, we'll have to go through different stages where security scans, code quality, this coverage and the creation of a review environment will need to be successful in order to be able to merge the changes into the main branch. Delany as the team lead will review this merge request. He can take a look in the changes that were made. Select multiple lines of code to review them if necessary. And all right, going back to the main page of the merge request, Delany wants to try the application using review apps which is an ephemeral environment that gets created thanks to GitLab Kubernetes integration. This environment allow us to try the application. Here, Delany can click around and try the responsiveness of the website. That is the main concern and fix the team is attempting to do. It looks like the site responds well to different window sizes. All right, back into the merge request page. Here we see that code owner's rule has been configured requiring approval from Delany if any changes to the CSS have been done. We can also notice that not security vulnerabilities were introduced by this merge request. Delany expands the view for a full report and everything seems compliant and okay. All right, it seems we are ready to merge. Clicking on merge will start our production pipeline. Again, a series of automated steps that when successful will deploy our application to production environment. We are confident that everything will work out. Nevertheless, we can take advantage of GitLab metrics and see with our own eyes how our new deployment is doing in real world. We can configure custom monitoring endpoints using GitLab integration with Prometheus, monitoring key metrics of the app such as requests to the subscribe endpoint. Monitoring this endpoint allow us to see that the subscriptions are back on the rise. That's great. The team has solved the problem and the business metric is back on track. If you made it this far, you probably want to learn more. Scan this QR code to visit GitLab Learn.