 Hello, my name is William. Let's learn today how no matter the distance or time zones, GitLab and its version control and collaboration tools can help Sasha and her team deliver software and execute on ideas. This is a distributed team with one idea. They want to build an e-learning platform. They are all located in different regions and time zones. Such differences become irrelevant when they are all brought together by GitLab, a single application where they can plan and execute their idea, putting together different roles and expertise. Initially, business and architecture folks define and plan the steps to create the e-learning platform. They prioritize and assign the work to other team members. Let's follow up on a normal day of work. What does it look like? First, the designer and developer need to create an initial version of the platform website. To do that, the designer in this case will start from the issue where this step is described. By using GitLab and Figma, the designer can work on professional mockups and quickly upload them to GitLab to its corresponding issue. It's a matter of right-clicking, finding the issue and clicking on upload. That was easy. Now, with the initial design on GitLab, I can collaborate with Sasha, the developer in charge of creating the initial version of this. As the designer, I can select specific parts of the design and comment or explain further how I want it to look like or behave. For example, I want to initiate a thread on this chat widget. Alright, now when Sasha, the developer, checks the issue, she can see the design and read the designer comments. In this case, it's not clear for her if the widget icon should look like that on the footer, so Sasha just asks this question in the open thread. The designer reads Sasha's comment and question, fix the mockup and uploads a new version to the issue. Here we can see that the design asset is under version control. We are using the last one where the fix has been added as per Sasha's suggestion. The thread gets resolved and it's time to code. From this issue, Sasha will create a merge request. By the way, this team has adopted GitLab flow. Sasha creates an initial version of the main page using the web IDE. She puts the code there and alright, so is this it? Commit the changes and is it done? Well, no yet. Let's bring our attention for a second here. The merge request creates a new branch where Sasha will commit this code. This will help me to have short-lived branches during the development cycle. Moving on, once I add a meaningful commit message, in GitLab I have configured code owners, which in this case, before merging, I need approval. Someone to review the code, so just changes and so on. In this case, this other developer has been identified as the approver based on the file extension. Code owners is configured to select this person as the approver if the file being commit is .html. Now, as the approver, I can review what has been commit. In this case, while reading the code, I can make multi inline review and comments. I will suggest Sasha to separate the JavaScript widget and code from the main website HTML. And same goes for the CSS file. It's better to have it in a separate location. Well, that was it. Sasha, the developer, reads the code review along with the suggested changes and it starts to implement them. Using the web IDE, she can create folders to put the JavaScript and CSS codes in different locations. She can quickly work on that without leaving GitLab. Once she's ready, she will commit the changes and lastly resolve the threads in the code review conversation. Alright, now as the approver, with all the threads resolved, I am okay with the changes. So, I will approve and merge it. As we can see here, this will automatically start GitLab CI CD pipeline. We'll talk about it later. Once deployed, thanks to GitLab CI CD, this is how the main page looks like. Not bad for a first iteration, right? I've got the feeling this widget will be reusable. So, let's go back to GitLab and create a code snippet. The chat widget will be needed many times. So, instead of having to look for it in the code base, I want to make it available as a code snippet, this in order to ensure component reusability. In GitLab, by clicking on snippets, I can paste here the code and create this file that corresponds to the JavaScript widget or chat widget that we have been using before. Great, now I can reuse this snippet and embed it in other parts of the project if I need to. So, what if I want to edit the main website by adding the widget snippet? Let's do it. All I have to do is to paste a URL of the snippet. Okay. Oh, it didn't work. Why? Well, because I was trying to commit to the main branch, which is configured as a protected branch. In addition to that, we also have code owners configured. So, to make any change, we need to create a merge request. Remember, this company adopted GitLab flow. Thanks to this feature, we have protected the main site and any change will be done only after being reviewed and approved. As organizations accelerate delivery through DevOps, controlling and managing different versions of the application assets from code to configuration and from design to deployment, it's incredibly important. With GitLab, this team here can have velocity with robust version control and traceability, plus enabling them to give structure to their ideas and to work in a distributed and asynchronous environments. Stay tuned and let's continue learning at GitLab.