 On today's Visual Studio Toolbox, Brian Randall shows us how to do pull requests in Azure DevOps. Hi, welcome to Visual Studio Toolbox. I'm your host, Robert Green, broadcasting from the cozy confines of my home office, and joining me today is Brian Randall. Hey, Brian, how are you? I'm great, Robert. How are you doing, buddy? Good. This adds new meaning to the cozy confines. It really does. Usually, I'm in Studio B when I'm in the cozy confines, but now I'm home. This is our first episode from home, so we think it'll go well. We'll improve the quality over time. I just got a brand new microphone, so our next one will be a little bit better, and we'll just do what we can do. Brian, today, what are you going to talk about? Well, I love DevOps, and Azure DevOps is one of the products that you use. It doesn't. Developers should love it, and even organizations should love it, because it makes things better. Rub a little DevOps on it and make life better. They should. We've done a few episodes in this show. I know on.net's done a few episodes. There's entire shows on DevOps and Channel 9. What are we going to cover today? Well, the great thing about the product is, on one hand, it's very return stable, but the team is always looking to gather customer feedback, and in one area that is used by a lot of developers is the pull request feature, which is how we basically do code reviews when using Git as our version control technology with Azure DevOps. So by product, we're talking about Azure DevOps services, correct? That's correct. We're going to focus on the Cloud-based version today. The changes we'll see are in preview, and I'll show you how to get them if you want them, and then in the next three to six months, they'll appear as well on-premises with Azure DevOps Server, the renamed version of Team Foundation Server. Well, let's just get right into it with a blog post from the team. We'll include this link in the show notes, but what you'll see here is the team is talking about the feedback they got and the changes that they've made. But reading a blog post is one thing. I'd rather show you, Robert. You okay with that? Yes. Yes, indeed. So I've already created a team project called VSToolbox inside one of my organizations. As you can see, I've got a code repo here set up with some basic history. What I did was I created an ASP.NET Core website, and I did that with Visual Studio 2019. You'll see here in the Team Explorer window, I'm connected to it, and I have the solution already open. Now, what we're typically going through here is this process where I as a developer am going to do some new work. But before that work is approved and shared with my team and ready for possible deployment, I'm going to want some kind of code review. I'm going to want someone to look at my work and make sure I did a good job. In addition, we might have some type of policies where we make sure that the code compiles, maybe unit tests that run, maybe that we've done some secondary validation. Whatever that is, we generally wrap in what we call the pull request process. Back over on the Visual Studio, sorry, my browser and on the Azure Devils website, you'll see I've got a simple PBI here, and I've got my task, build the base website. What do you have, a simple what? PBI, product backlog item, sorry. I've chosen the scrum template. I'm using work items to track my work. This basically represents the business need. Got it. Thank you for that. I've got a developer task here where it says build the base version. And if I click the link to open it up, I get access to a menu here that lets me come over here and define a new branch. So a branch is a mechanism in version control and in Git that we use to isolate our work from our team. So by clicking this, I'm going to get two benefits. Number one is it's an easy way to create the branch. So we'll call it features slash 255 website work for lack of a better name. I tell which repo I'm using, which branch I'm basing it off, which is off the master branch. And then I have this ability to link my work items. I love this because as I've gotten older, my brain can't keep everything in my head. And having work items and linking them to my branch helps me track back to the business reason and why I'm even doing this, why am I messing with the code? And then later, a couple of weeks down the road, when this is a production, if a bug comes up, we might be able to figure out, oh, is this work? And maybe we need to improve our process. So I really like this ability to not only create the branch, but link it to the work I'm doing. So I'll hit create branch. And when that's done, it takes me to the repo view and shows me that this is what it looks like on the feature branch 255-website work. Now the problem is, this is something I've only done up in the cloud. So I have to go back over to Visual Studio and I'll go over to the team explorer and I'll click on branches. What I do, you'll notice that I'm on the master branch locally and up in the remote, it currently only thinks that there's master. And that's because whenever you work with Git, you're in this constant dance between keeping in sync with what's up in the cloud or another remote, which can be on another server. So what I'll do here is I can right click on master and I can do a fetch. Now what it's gonna do is it's gonna go up there and say, are there any changes on master I need? And are there any new branches? And sure enough, you'll notice now I have feature 255-website work as a remote. And if I double click on it, that will check out that branch locally. And now any of the changes I make inside Visual Studio or even using a notepad or Visual Studio code will only be on that branch in my local repo until I'm ready to share. So that's part one. I'm ready to go with my work. And this is all very much the same. This is no different today with the new feature. It's gonna be the pull request later. So I'm gonna make a couple of changes. First thing I'm gonna do is modify the homepage. Currently the homepage just says welcome. And I'm gonna say welcome visual studio toolbox. Watcher's viewers, I think is a better word. There we go. All right, a tour de force of programming prowess. Wow. I'll have five of it just to make sure it works because you never know, kind of fat fingered something. We'll give that a go. And now Robert, you're gonna wanna hire me to build your next website, right? Amazing. Wow. God, I'm just, I'm excited. All right. It's been rigorously designed, coded and tested. It's amazing. It's amazing. So I'll come back over here to Team Explorer and I'm gonna switch view to changes. And what we'll see is that there's my one change. I'm gonna stage the change, which basically says I wanna add this file when I commit. I'm gonna link it to the work item. And I'm gonna add a message, update homepage view. Now I'm just gonna commit it locally. It's still on my machine. And I'm gonna do one other change. Often what happens when you're working on a feature, it takes you a few commits to get all the work done. So let's update the privacy page. And I think we'll do something like you really expect privacy in 2020. All right. But we'll build it. We're gonna just have to trust me that it works. And let's commit that update privacy page. So see if the work item. Now I'm doing this to show you how this looks in the pull request process. Because we've linked the task to the branch, Azure DevOps is gonna link it automatically. I'm showing you the process in case A, you wanted to change work as maybe I have multiple tasks within the particular branch. There's a number of reasons why you might do this extra step. And now I'm gonna click the stage changes and commit. So at this point, this is all normal. And finally, I wanna click the changes from my machine up in Azure DevOps. And I do that by doing a push. So I'll come over here, it's like sync. It shows that I have two outgoing commits and I'll push it up to Azure DevOps. At this point, nothing's new. However, now let's go back into Visual Studio, sorry, to the web browser in Azure DevOps. And if we look at my history, you'll see there's those two commits I just made. But I'm on that feature branch. So we'll just switch over to master, show the difference. But notice it's saying, hey, you updated this feature branch. It's kind of encouraging me saying, are you ready to share this with your team? It even shows you a button to create a pull request. Exactly, it's drawing me down. It's calling me home. So I click create pull request. And this is where we're gonna see a redesign. If you go take a look at the old version, anybody wondering, oh, Brian, I must see your screen. Ah, because you have to make sure that you come into your user profile here, click on the dot, dot, dot, select user settings, and then go to preview features. Oh, you can choose which one. Nice. Yeah, there's a bunch of them. And this is the feature I'm using, the new repos pull request experience. Now I'm gonna click this box. It's gonna say, why you do this? And I'm gonna say demo. And I'll click turn off, close the screen, and now it goes back to the old view. So I can just show you briefly what the old view looks like. So the biggest change that's obvious is that files and commits are much further down on the screen. And what we're gonna see is when we switch back, they're gonna be moved up to the top. There's also a couple other subtle changes I'll go through on the screen. So to rehash, to turn on the new experience, come to your user icon, dot, dot, dot, user settings, preview features, scroll down, and we want new repos pull request experience. Click the X, the screen will refresh. Looks like we found a preview bug, not a problem, we'll come back to pull requests. We'll say create pull request, and now we have the new view, which shows files and commits as kind of a tabbed interface. So at this point, I'm getting ready to... And in files, it shows you the old and the new side-by-side. Is that new, or do it always do that? This has always been available. The key thing is you can do side-by-side as well as you can do inline, whichever you prefer. And then you can go to each file individually and look at them in gory detail, so to speak. And then commits, you'll see there's an individual commits and you can drill down into them as well. Now back in the overview, what it's done here is if you only do one commit and then create a pull request, they will copy the commit data into the title and description. However, because I have more than one commit, it's saying you need to do a title and a description. So I'll come over here and say I'd like to do the title, updated home page and privacy page. And then I can write a description here, you can do mark down, and you'll notice it's previewing it down here with the fonts. And of course, it wouldn't be modern web development if we didn't do emojis, who doesn't love tacos. Of course. So you can do that, but you also can say, you know what, there's some good data in the commit messages. And I don't wanna make my teammates go through all of the individual commits. So if you click this button, it'll copy the text from the commit messages right in there for you. So that's really nice as well. And that way you don't have to repeat the commit messages in the title. Exactly. Typically what we do is first of all, we coordinate through our team on how we want to verbalize and write up our messages. And so we'll typically have a process on both the vernacular use and what's a good title versus a good description. In particular, people like to limit the number of words. So when you look at commit history, you can see that first 60 to 80 characters very easily. Because you'll typically have more than, you might have more than a couple commits. You might have worked on 10, 20, 30 different things in a day, committed them all. And then your title could be the stuff I did today, basically, right? Brian's Tuesday work. Exactly. And once again, depending upon how your team wants to do this, you'll work out a good way to have a good message there. We're gonna talk about how this affects the summary at the end. So at this point, I'm telling people what the general gist of what I did was, there's specific details in the description and then I need reviewers. Now, we can use the feature called branch policies, which I've already turned on and you could have had required reviewers. You can click this button and it'll add them automatically as well as I can add optional reviewers to look at it. Now I can come in here and add additional work items if I wanted to. Typically, if I see this happening, that's kind of a smell. We typically want the batch of work to be focused and the developers should have already linked those up. But sometimes you forget and you're like, oh, I need to link this other work item because I drug this in. So you get the ability to do that and with the ability to do what are called tags. Now, once I hit create, now I'm at the view of what's been, what's going on behind the scenes. And you'll notice this is a new cleaned up status check view that was kind of hidden in the previous versions. Number one, you might have lots of validation items going on and you'll note I even have one right now. It's running a build. This is a process that I've turned on through what are called branch policies and it's checking to make sure that my code not only compiles but my unit has passed and anything else in my build. Then you'll notice it says, hey, the build turns out it's all happy. However, you need one reviewer besides the author to approve this. So I'm gonna switch over to my other browser where this user is already logged in and I'll come over here to pull requests and you'll see that I've got a pull request assigned to me. This is my other persona. So I'll click on the link. I get that same screen but notice I now have an approved button and I can come in and look at the files and you'll note this little comment widget. I can put comments and you can have rules that say the comments must be responded to. You could require the developer to do some more changes before it's committed but that's a demo for another day. So for now, I'm gonna say I trust my developer. These changes don't look too scary. I'll approve. Once I approve it, I can go back to the original developer. They see it's been marked to approve. We got this nice set of check boxes, all the summary detail. The reviewers over here are happy. I could add additional reviewers. If I needed to, I can update tags. I still have the ability to modify the pull request here until I finally go to the last step which is complete. Now this has also been enhanced. There are still the same four choices we have before but they've updated. Can you go over those? Can you go over those four choices? Absolutely. So there are four different choices here. Merge, no fast forward, squash commit, rebase and semi-linear merge. So let's go back to them and talk about real quick. The merge no fast forward is one that a lot of people aren't fans of because it ends up getting you what we call the guitar hero version of your history where you see all these lines crossing like the subway in London. But what happens is you'll see this nice visual indicator. What happens here is it shows the point in time where the work was done on the side and then links it back up. Now the second one is squash commit. And squash commit is a very popular open source. And this is where, look, I don't care how you got here. I just want to know at some point in time we took a bunch of work and brought together. That means there'll be only one commit on the code line. Then we have the one I typically use which is rebase and fast forward. Rebase and fast forward says, I care about the changes but I want to make it look like it's a linear progression. I use this a lot when I dev by myself and I isolate my work in branches because sometimes I have to pause and not come back to it for a day or two and do hot fixes or whatever things. So I like this because I get to show how I got there but it looks like just a progressive day to day work. And then finally there's something called semi-learning merge which I've never used. It is a combination of fast forwarding and moving the changes up the branch so they look like a continuous piece in time but it maintains that separate side batch of work to show you the different branches that were going on. All these are documented and the docs are very good and have these nice animations in them. So as I said, I would typically do a rebase fast forward and then we have a couple completion options. Now I want to point out one change in the UI. You notice it says rebase uses existing messages from commits. Now the reason is because we're going to keep each of the commits. That's the same effect as picking the merge no fast forward. It will keep each of the commits. However, you'll notice there's a checkbox now that says you can customize the merge message. So here's what's going on. We're going to have the individual commits and their individual messages and by default we take the pull request info and make that the commit message for the merge commit. Remember, we're taking the data from my feature branch in the master. This allows you to customize it. However, if you do a fast forward, it's not going to let you do that because it's just going to say, look, I'm not going to show that this was a merge. It's just going to look like two commits that were done on the master, all right? So notice the difference here. Rebase fast forward gives you two commits on top. Merge no fast forward is going to give you two commits and the third commit for the merge and the squash commit is simply going to get rid of those and give you one commit. And the default is the merge no fast forward. Exactly, but I'm going to show you just a second as we wrap up how you can control what your team uses. Okay? So as I said, I'm going to do a rebase fast forward. The last two items require you to think on your team. Number one, do you want to complete the associated work item? I typically don't complete my work items until it's in production. Some teams like to say, well, I did the work, I'm done. So we'll leave that default. And then finally, what do we do with this feature branch? If the pull request is considered successful and we're done and we're happy with it, I like to delete the feature branch because no more work is going to be done on it. And so I'll hit complete merge. It's merging the pull request with this nice summary update and it's all done. There's lots of other hidden gems in this new UI that I'll encourage you folks to look at and give feedback because this is not a complete feature. By the way, I mentioned a couple of times that I used branch policies to encourage me to do a good pull request. Let me just show you where that's at and you guys can take a look at it later. Or maybe I can come back, Robert and do a second show on this. I'm always happy to have you back, Brian. If we go to branches and find my master branch, you can come over here to the dot dot dot menu and select branch policies. And thank you Firefox for that helpful tip. You'll notice here that I've turned on require a minimum number of reviewers. And currently I just set one because there's just one of me but you can specify the number of people, specify rules around that. You can tell it to look for linked work items which I did. There's additional items here and one of them, Robert, is limit merge types. So if you're saying, you know, we're not gonna allow squashes. We want people to always show their work. We're gonna turn that off. And of course you can do this at the project level. Right, because this is a setting for this particular project, not Azure DevOps everywhere. Correct. This is actually a policy for just the master branch in the VS Toolbox repo. So you can have different settings by repos and projects, absolutely. And then the big one here that almost everybody I know who wants any sanity for the development team uses this. This is a build validation rule. The build must pass. Now typically this is a quick build. It just does quick unit tests, make sure it compiles. It doesn't do any deployments. It doesn't do any large integration tests. It's basically a smoke check to say, look, you've done your basic business. The humans will do their validation but also we're gonna get this extra check from the computer to make sure you didn't leave out a file, that you didn't add some component that's not supported, et cetera. And do you set that up on the commit or on the pull request? You link this to the pull request. Separately what's gonna happen is when the merge occurs, then a build can also execute. You could, by the way, set up a build that runs every time someone commits and pushes. Right. Also feature branch as well. You can have builds running all the time based upon what you need and what level of validation you want. In addition, the developer can say, you know what, I'm a little worried about this. I'm gonna go in and clone the existing build and I'm gonna turn it on just for my branch and run it. There's lots of choices you can make. Again, another talk about at great length. So that's it in a nutshell. It's bottom line refinement of an overall good experience that makes it a great experience and I'm really happy with the changes they've made. I think teams that are using pull requests with Azure DevOps will really be excited so they should take a look. Very cool. So again, this was basically a review of how you do pull requests using Azure DevOps and then we focused on the new UI, which you can turn on and play around with or choose to use the old one. We'd encourage folks to try the new one and provide feedback because as you mentioned, it's not quite done yet. Exactly. Awesome. Thank you so much for coming on. Hey, thanks, Robert. Hopefully I gave you enough information to think deeply about pull requests at night. Absolutely, absolutely. So I hope you guys enjoyed this. It's great to be back and now that we have our remote setups working, we're back to doing regular shows. So we will see you next time, very soon on Visual Studio Toolbox. [♪ upbeat music playing in the background, with electronic music playing in the background.