 Hi, I'm Cesar Saavedra, Technical Marketing Manager at GitLab. In this video, I'm going to show you how GitLab empowers GitHub stakeholders to effectively collaborate on infrastructure updates. Let's get started. GitOps manages infrastructure changes using DevOps best practices. The ability to foster collaboration between infrastructure and operations engineers as well as developers is a core GitOps capability. This organization has the following GitOps team structure. Satcha is a software developer and development team developing microservices. Devin is a DevOps engineer in the operations platform team maintaining the Kubernetes clusters and Sydney is a database administrator in the infrastructure team. They will all collaborate on projects under this group, which contains two subgroups, one for the applications and one for the infrastructures code. This separation of roles and concerns between applications and infrastructure optimizes the work and collaboration among GitOps stakeholders. In this scenario, Satcha developer will ask Sydney, a database administrator, to provision a new database. Sydney, in turn, will loop in Devin, a DevOps engineer as a consultant. Satcha has been tasked to work on an enhancement for a Java microservice that calls for the creation of a database. She would like to collaborate with the operations platform and infrastructure teams and has created an issue under the AWS infrastructure project and assigned it to Sydney, the database administrator from the infrastructure team. At this point, Sydney creates an MR and using the AdSign annotation in a comment, tags Devin from the operations platform team since they run Java microservices on Kubernetes clusters. Sydney opens up the Web IDE to start to work on the infrastructure-related updates to the project. Sydney is using AWS, but the same would apply for other cloud providers like Google or Azure. Sydney creates a configuration file, MySQL main.tf, for the creation of the database. She's using Terraform for the infrastructure updates. Since she owns this file and wants to ensure that the merge does not happen without her approval, she checks that her GitLab handle is listed in the CodeOwners file. CodeOwners outline the exact GitLab users and groups that own certain files or paths in a repository. They can streamline the merge request approval process by finding the right reviewers and approvers for a given merge request. They also help identify who to contact for other questions about this file. Sasha notices that the MR has some activity and checks the newly added Terraform file for the database she requested of Sydney. She notices that the database allocated storage is too small and makes an inline suggestion to Sydney for an allocated storage size of 5 gigabytes. Inline suggestions and comments speed up the code review process and can help increase code quality. Devin has an item in his to-do list and goes to the MR in which he has been tagged. He notices the version of the database in the Terraform file and makes an inline comment about possibly bumping it up to a more recent version. He also sees the hard coding of the database admin username and password and makes inline comments about this to Sydney. Devin observes that there needs to be a way to show or report the database information like the connection URL to the end user. He adds a general comment about this at the bottom of the MR. At this point, Sydney notices that there are a resolved threads in the MR and proceeds to address all the feedback from the operational platform and development teams. Sydney proceeds to apply the inline suggestion from Sasha. She then decides to create a new issue out of Devin's inline comment about bumping up the database version so that she can tackle it in the next sprint. To address Devin's remaining comments, Sydney replies to his general comment requesting he create an issue for the next sprint. For the two inline comments, she lets him know that she will parameterize and mask the database admin username and password. Sydney checks that all threads have been resolved and proceeds to mark the MR as ready. The MR will also need her approval before it can be merged since she is a code owner of a path affected by this MR. Sasha notices all items have been addressed by all GitHub stakeholders and proceeds to approve the MR. Notice that the MR is now ready to be merged. We have gone over an example of how Gila can help platform operations, infrastructure and development team members to collaborate on GitHub's tasks to increase visibility and quality of code changes, leading to greater accuracy of fulfilled requests, greater infrastructure stability and improved release velocity through team review and validation while sharing the same consistent user experience and workflow. I hope you enjoyed this video and until next time.