 Hi, my name is Sean McGiven, and I work on the discussion team here at GitLab. Among other things, we in the discussion team are responsible for issues, issue boards, commenting on issues, including markdown and emoji reactions, search, notifications, including to-dos, and merge requests, including code review. And it's code review I'd like to talk about today. At GitLab, we code review every single change we make. Nothing gets committed directly to master. A typical flow would look something like this. A developer makes a change on their feature branch, tests it. When they're happy, they push and create a merge request. They assign it to a reviewer. That reviewer will look at the diff and have line comments as appropriate and higher-level design-oriented comments when needed as well. They assign back to the author and they address the comments. This can go around in a cycle for a little while. Once both are happy, they assign to a final reviewer who has the ability to merge the merge request. They will do their own review, and again, if there are any comments they have, the author will need to address those either in the discussion or in the code itself by making changes. Once the reviewer is happy and the build is green, we will merge the merge request, but not before them. So, here is an example merge request on my local instance, with which I can show you some of these features. I, as the administrator user, created this merge request recently. We can see here that it has conflicts, and we can also see that we have some comments. Each comment on a line is a resolvable discussion as well, so I can jump very easily between these comments and see what's happening. Basically, there are three comments here, and then my final reviewer has also added two other things. First of all, I need to remove conflicts, and secondly, these changes need to be made in a separate branch as well as master. So, let me start with resolving the conflicts. Normally, when you get conflicts, you have to resolve them on the command line, and it can be a painful process. In GitLab, we have the ability to resolve some conflicts within the UI itself without going to the command line or to a text editor, so I'm going to use that feature here. In this case, the conflict is very simple. My branch started when the current version was 3.4.0. Since then, we've added a lot of other versions, and my change to the changelog file is no longer correct. If this was a simple conflict, I could just pick to use my version or the version in master, but in this case, I want both changes. I just need to make sure that my changes are correct, so I'm going to use the edit inline feature, and then I will edit the conflicts just like I would locally to create a new 4.1.0 version in the changelog, and remove the conflict markers from the file, scroll down to make sure there are no other conflict markers, which there aren't, and then the commit message is the same as the commit message I would get on the command line. I'm just merging master into my feature branch, so I'll commit those changes. Once those changes are committed, the merge request will update, and you can see now that I have the option to merge this because there are no longer conflicts, but I still shouldn't merge this because I have code review comments outstanding. First of all, my first reviewer has said, instead of memory, I mean storage, and also my second reviewer has agreed, so I need to address that. Then they have a suggestion about a better error message in the case where the limit is exceeded, and finally, they have a code style suggestion. Let's deal with the first one first. If I look at the changes tab, I can see that I've changed three files. One of those is the changelog, which we just addressed. The other one is gitlabaccess.rb, and the final one is gitlabaccess status.rb. In both of these two files, I need to update memory to say storage, so I'm going to open the branch in a new tab, and from within here, I can hit the T keyboard shortcut, that's T for tango, and I get a fuzzy file finder, so I need gitlabaccess.rb, which is the first result when I type that. I can then edit this within the file editor, so I can just search for everywhere I see memory and change that to storage. So memory is here as well. Let's do we see it here. Once I've made these changes, I can commit direct from the UI. Let me just check that there are no more occurrences of the word memory. I'll update the commit message to say rename memory to storage. One disadvantage of making the changes from the UI is that I can only make a single commit per file I've changed. I can't change both of these files in the same commit. If I was doing this locally, I would squash the changes into one commit as that would be the correct level for this change, but for the purposes of this example, it's much nicer if I can do it in the UI. Then the other file was gitlabaccess, and then gitlabaccessstatus, so I need to update that as well. Gitlabaccessstatus, and again that's the fuzzy file finding with T. I can edit this and again just change memory to say storage, and this will just take a little while, which I appreciate won't be synthesizing viewing, but hopefully the idea is coming across even as I just basically do find and replace on this storage, and then finally down here, and then again rename memory to storage, and I can commit my changes. So if I go back to the merge request now, and look at the discussion tab, I will be able to see my new commits after refreshing, because the disk tab is cached. So if I do that now, I can see that the storage limit reached error instead of the memory limit reached error. So if I look at the discussions, I don't see any of them on the changes tab, because none of them apply to the current diff, but I haven't addressed all the discussions, so they are still visible in the discussion tab expanded until I explicitly mark that I have resolved them. So this one is done, I can mark resolved discussion. This one I haven't done yet, I need to do that now. So let's change this message in gitlabaccess.rb, and just edit the file again, find the message, we won't mention the limit just now, just for simplicity's sake, and we need to add the word gitlab to the front of it, just so it's clear where the message is coming from. Okay, so let's update storage error message. Okay, so that change is made. I could say done here, but that won't resolve the discussion, I need to explicitly click comment and resolve discussion in that case. So I'll do that. Now I have two out of three discussion resolved, the only one that's unresolved is this. This is a style comment, personally I prefer the other way, so I'm going to say personally I prefer this like it is, keep it, and then I can also mark this discussion as resolved. So once that's done, these discussions are still visible, but if I refresh the page again, all these discussions are collapsed because they have been resolved, and you can see that there is a system note saying that I resolved all the discussions, as long along with the commits I've just made in the UI. So the comments are resolved, I can expand them again if I need to, but in this case I don't. The conflicts are fixed, I can merge this. On my local instance, I don't have CI running, which is why this pipeline is pending. Typically we would say merge when pipeline succeeds, I'm just going to merge this immediately, and that will ignore the CI status of the commit and just merge immediately. So I've done that now. So this change is now a master. The final thing I need to do is make sure this change is in the 4.0 stable branch. So I need to pick into branch, I need to pick 4.0 stable, and I can either start a new merge request with these changes or just make the change directly into that branch. In this case I'll create a new merge request just in case there are any other issues. And this is the equivalent of cherry picking on the command line. I can just customize the merge request if I want here, but I will leave it as it is. This is mergeable, so again I can just merge that immediately, and now my changes are in both the master branch and the 4.0 stable branch. And there's a full audit trail of both my initial change and the decisions I made with the review comments, and then the second change where I needed to propagate that change to a new branch. There's one other thing I'd like to talk about here, which is to do with CI, and that is CI and review apps. So if we look at this merge request from the gitlab.com website, so this is both a merge request on gitlab.com and it is a merge request for about gitlab.com site. We can see here that the pipeline has passed. If I click on that I can get the details of how the pipeline looks, and I can also get a review app. Review apps are a new feature in GitLab where a project can be configured to deploy the code from the branch to a special location where a reviewer can see the code as it is. So this site is a static website, so I have the option to view the RS direction copy edit website live. So I can see these changes on gitlab.com. Now this takes me to the home page. Thankfully the author has provided a convenient link for the current version and the review app. And here we can see the pipeline as loaded and the stages it went through. So it went through a build stage and a lint stage, then it went to a review stage and the review stage is the point at which the review app is deployed. If I click on this, this is a link to the environment in which it's deployed. You can see that there are two versions of this. I can roll back to the previous version if I want to see that, or I can redeploy the current version if there's a problem with that. So this is the new version, this is the old version, and just by flicking between the two I can see that there are clearly changes. On the new version, instead of reviewing the markdown as plain text, I can review the rendered markdown, which is what users will see. So that gives me a lot of advantages in that I don't need to check out the code locally and I don't need to run the repository myself. I can just view the site as it would appear once this was merged directly from within my browser. And that's what we're trying to do at gitlab with all of our code review features. We're trying to make sure that as much as possible anyone can contribute from within their browser and you can go directly from idea to production within gitlab itself. Thank you.