>> On today's Visual Studio Toolbox, Brian Randell shows us how to do
pull requests in Azure DevOps. [MUSIC] >> 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
Randell. 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. So this is our first
episode from home. 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. We'll just do what we can do. So Brian, today, what are
you going to talk about? >> I love DevOps and Azure DevOps is one of
the products that I use. >> Who doesn't? >> Developers should love it. 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, and 101 .NET has done a few episodes. There's entire shows on
DevOps in Channel 9. So what are we going to cover today? >> The great thing
about the product is, on one hand, it's very
mature and 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. Then in the next 3-6 months, they'll appear as well on-premises
with Azure DevOps Server, the renamed version of
Team Foundation Server. 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.
Are you okay with that? >> Yes, indeed. >> Fantastic. 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 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 are run. Maybe we've done some
secondary validation. Whatever that is, we
generally route to what we call the "pull
request" process. So back over on the Visual Studio. Sorry, my browser, and in
the Azure DevOps website, you'll see I've got
a simple PBI here, and I've got my task, "build a base version of a 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. Thank you for that. So I've got a developer
task here which says, "build the base version." 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 1 is, it's an easy
way to create the branch. So we'll call it
"features/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've 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 am I even doing this, why
am I messing with the code?" Then later, a couple of weeks down
the road, this is a production, if a bug comes up, we might be able to figure
out, "Was this work? 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 it 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 on 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." When 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. 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 could 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 this is going to do is
it's going to go through and say, "Are there any changes on master I need and are there any new branches?" 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'd
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 1. I'm ready to go with my work. This is all very much the same. This is no different today
with the new feature. It's going to do the
"pull requests" later. So I'm going to make
a couple of changes. First thing I'm going to
do is modify the homepage. Currently, the homepage just says
Welcome, and I'm going to say, "Welcome Visual Studio Toolbox
Viewers," I think is a better word. There we go. A tour de force
of programming prowess. I'll F5 it just to make sure it works because you never know, could've
fat-fingered something. We'll give that a go. Now, Robert, you're going to want to hire
me to build your next website. Amazing. >> Wow. >> God. I'm excited. >> It's been rigorously designed, coded, and tested. It's amazing. >> It's amazing. So I come back
over here to Team Explorer, and I'm going to switch
view to "Changes." What we'll see is that
there's my one change. I'm going to "Stage" the change, which basically says I want to
add this file when I commit. I'm going to link it
to the work item, and I'm going to add a message,
"Update homepage view." Now, I'm just going
to commit it locally. It's still on my machine. I'm going to 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. I think we'll do something like, "You really expect privacy in 2020?" Though we'll build it, you'll just have to trust me that it works, and let's commit that
update privacy thing, associate 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 going to
link it automatically. I'm showing you the
process in case A, you wanted to change
work as maybe you have multiple tasks within
a particular branch. There's a number of reasons why
you might do this extra step, and now I'm going to click the
stage, "Changes" and "Commit". So at this point, this is
all normal, and finally, I want to put 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 to the
web browser and Azure DevOps, and if we look in 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 on to master, show the difference, but
notice it's saying, hey, you updated this feature branch. It's encouraging me saying, are you ready to share
this with your team? >> It even shows you a button
to create a pull request. >> Exactly. Its drawn me
down, it calling me home. So I click "Create a pull request", and this is where we're
going to see a redesign. If you go take a look
at the old version, and you might have wondered, well,
Brain, I don't see your screen. 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. >> You can choose
what you want. 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 going to click this box, it's going to say why you do this? I'm going to 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 to the screen, and what we're going to see
is when we switch back, they're going to be
moved up to the top. There's also a couple
of other subtle changes all 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 with a pull request, we'll say "Create a pull request", and now we have the
new view which shows files and commits as a
tabbed interface instead. So at this point, I'm getting ready. >> In files, it shows you the
old and the new side-by-side. Is that new, or do
you always do that? >> This is always been available. The key thing is you do
side-by-side as well as you can do inline,
whichever you prefer, and then you could go to
each file individually and look at them in gory
detail, so to speak. >> Got it. >> Then commits, you'll
see there's an individual commits and you can drill
down to them as well. Now, back in the overview, what is 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, I could do markdown, and you'll notice it's
previewing it down here with fonts, and of course, it wouldn't be modern web
development if we didn't do emoji's, 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 want to
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, write it in there for you. So that's really nice as well. >> In 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 those in 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 is 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-80
characters very easily. >> Right. Because you'll typically
you might have more than a couple of commits you
might've 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. "Brian's Tuesday Work". >> Exactly. 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 going to talk about how this
affects the summary at the end. So at this point, I'll tell 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 a feature
called branch policies, which I've already turned on, and you could have had
the 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 developer should have
already linked those up. But sometimes you forget
and you're like, oh, I need to link this other work
on because I dragged 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
going on behind the scenes, and you'll notice this is a new
cleaned up status check view that was hidden in the
previous versions. Number 1, 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 tests pass, and anything else in my build. Then you'll notice that it says, hey, the build, turns out it's all happy. However, you need one reviewer
besides the author to approve this. So I am going to switch
over to my other browser where this user's 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 Approve button. 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 can require that they'll produce more changes before it's committed. But that's a demo for another day. So for now, I'm going to
say I trust my developer. These changes don't look
too scary, all approved. Once I approve it, I can go back to the
original developer. They see it's been marked "approved", we got this nice set of checkboxes, 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's still the same four
choices we had before. >> Yeah, 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 slide
and then, links it backup. Now, the second one is Squash Commit. Squash Commit is very
popular in open source. This is where, look, I don't care how you got here. I just wanted to know
at some point time we took a bunch of work
and brought it together. That means it will 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 wanted to make it look
like it's a linear progression. I use this a lot when I dealt
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 hotfixes 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. Then finally, there's something
called Similarity Merge, which I've never used. It is a combination of fast forwarding and moving
the changes of 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
of completion options. Now, I want to point out
one change in the UI. It also 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
check box 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. 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 those are 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 [inaudible] >> 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. So as I said, I'll 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 Intel,
it's in production. Some teams like to say, I
did the work, I'm done. So we'll leave that default. Then finally, what do we do
with this feature branch? If the pull request is considered successful and we're done,
we're happy with it, I like to delete the feature branch because no more work is
going to be done on it. So I'll hit "Complete Merge". It's merging the pull request. We have 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, I used Branch policies to encourage
me to do a good poll request. Let me just show you where that's at. You guys can take a
look at it later . Or maybe I can come back, Robert, and do a second shell on this. >> 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 then select "Branch policies". Thank you, Firefox,
with that helpful tip. You'll notice here that
I've turned on require a minimum number of reviewers. Caroline just said one because
there was 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 merged types. So if you're saying we're
not going to allow squashes, we want people to
always show their work. We're going to turn that off. >> Of course, you can do
this at the project level. Because this is a setting
for this particular project, not Azure DevOps everywhere. >> Correct. This is
actually very narrow. This is actually a policy for just the master branch
in the VS Toolbox repo. So you can have different
cities by repos and projects. Absolutely. >> Yeah. >> 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 doing 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 really get
this extra check for the computer to make sure
you didn't leave out a file that you didn't add some component that's
not supported, etc. >> So do you set that up on the
commit or the pull request? >> You link this to the pull request. Separately, what's going to
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, also feature branch as well. You can have bills running
all the time based upon what you need and what level
of validation you want. In addition, a developer
can say, you know what? I'm a little worried about this. I'm going to go in and
close the existing build. I'm going to 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. I'm really happy with the
changes they've made. I think teams are using
pull requests with Azure DevOps will really be
excited. So you should take a look. >> Very cool. So again, this was basically
a review of how you do pull requests using Azure DevOps. Then we focused on the new UI, which you can turn on
and play around with or just use the old one. We 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. So I hope
you guys enjoyed this. It's great to be back, and now that we have
our remote setups working where back to
doing regular shows. So we will see you next time very
soon on Visual Studio Toolbox. [MUSIC]
