Introducing the New Pull Request Experience for Azure Repos
Pull Requests are a vital feature for many Azure Repos customers. We are excited to announce that our new pull request web experience is now available in preview! Not only is the new experience mobile-friendly and faster, we have also added several new features to help you review pull requests quicker and improve your overall pull request experience. Customers will see the preview option rollout in the upcoming weeks.
Please try out the new experience then let us know your feedback! You can try the new experience by turning on ‘New Repos pull request experience’ in preview through user settings or via a banner that will show up once the feature rolls out. After trying it, we would love to hear your feedback: New Repos Pull Request Experience Survey
Completion readiness summary in rollup view
A pull request with a large amount of policies can really clutter the view and make it difficult to determine the status of a pull request. To help get a quick picture of what the status of a pull request is, we have summed up policies in the overview tab. The rollup view will summarize the policies that are passing/failing and only surface failed checks. If available, the summary will show a snippet of the failure message from the check’s log. Re-queueing a failed policy is a one-step process. You can view all checks in a panel where you can also re-queue all checks and releases with one click, unless multiple actions can be taken on the check.
  
Add required reviewers per pull request
Often times, you want to be able to not just have required reviewers for branches set by policy, but also specific people from different teams to review your pull request and be able to wait on them. With the new experience, you can add reviewers to be required and wait on them to auto-complete. You can do this while creating a pull request or within a pull request in the reviewers section. You can also make existing optional reviewers required or can demote required reviewers to optional, unless they are required by policy.
  
Multiple Iteration select
Viewing only subsequent updates when there are several updates doesn’t always give you the full picture of changes made to files. When reviewing files in a pull request, you can now view multiple updates at a time by pressing shift and selecting which updates you’d like to see. So if you’ve already reviewed updates 1-3 but still need to review updates 4-7, you don’t have to view all updates or sift through one update at a time.
Add suggested changes and commit within a pull request
It is often tedious when a reviewer comments on your pull request with a minor change like a syntax fix that then requires you to leave the pull request experience, make the change, commit and push it, and update the reviewer. With suggested changes you can reduce the hassle by using the new “suggest an idea” option! You can include the change you are suggesting within your comment and the pull request author can accept the change without ever leaving the pull request experience. When you’re commenting, you will be able to see a preview of the diff. When you are reviewing you can choose to accept the change and make a commit for each change or batch the suggestions you are accepting to make a single commit for all the changes.
Auto-complete: wait on optional policies
Currently, when a pull request is set to auto-complete, it only waits on required policies that are set by admins. In the new auto-complete panel, you can choose to wait on optional policies as well. Once you have set auto-complete you can see all the policies auto-complete is waiting on when you “view all checks”.
Create pull request page – separate tab for the changes preview
When you create a pull request you can now preview the changes in a separate tab for files and commits the same as a pull request. This will help you ensure you have everything in order before you create the pull request.
Create pull request – wrong target branch warning
When creating a pull request, a user can sometimes select the wrong target branch by mistake and have unintended issues. The create pull request experience will now warn you when the selected changes are very large in an attempt to prevent this mistake.
Direct policy links given for reviewers added by policy
It can be difficult to understand why a reviewer is required by policy on your pull request and where the policy is being set. With the new drop down option you can click “View Policy” to directly go to where the policy was set.
View a team’s membership that is a required reviewer
Teams can be added as a required reviewer by policy and it can be hard to determine which user may be able to approve on that team’s behalf. Finding out who belongs to the group is now easier because you can click on the team’s icon and view all the members in that team without having to leave the pull request.
Improved mobile experience
The new experience makes quickly reviewing pull requests on your mobile device easier!
Improved performance
Early results show 3x the initial load improvement! The below metrics show the changes in apdex score and load time at 50th and 85th percentiles.
| Old Apdex | New Apdex |
|---|---|
| 0.719 | 0.924 |
Â
| Old 50% | New 50% | Old 85% | New 85% | Delta 85% |
|---|---|---|---|---|
| 0.875s | 0.158s | 3.072s | 0.937s | 3.28x faster |
Â
As this experience rolls out in the upcoming weeks, you will see a banner that will prompt you to turn it on. If you’ve dismissed the banner, you can also turn it on by going to user settings, then preview features and turning on the toggle for ‘New Repos pull request experience’. Once you’ve tried out the new experience, please provide us feedback through this survey to help us give you the best experience we can!
Light
Dark
81 comments
Like the view, but I am missing the full screen mode in this view. Will that be added?
Hi there!
I was trying out the new features, and are awesome. The only thing is that the “WIP …” in the name of the Pull request is not making it as a draft automatically.
It’s a small feature that was nice to have
The test coverage check seems to have taken a step backwards, it used to alert you to the fact you’ve failed it and why. Giving details on which files had specifically failed. Now it just says “Coverage status check failed for Message Processor PR”. You can’t click it for more info – Am I missing something or has that info gone?
Build status is not showing.
When I’ve created PR, build got triggered and passed. In earlier version build status use to showed on the PR screen, now its not. Please look into it.
Please consider enabling a commit-at-a-time workflow for reviewing PRs, as per this developercommmunity discussion
My team tries to provide many commits with detailed commit messages in each PR. When using Github prs, this allows the reviewer to work through the changes from the earliest commit, one commit at a time, leaving comments on each commit. Github provides ‘previous’ / ‘next’ commit navigation links the ‘n’ and ‘p’ keyboard shortcuts to make this workflow very convenient.
Unfortunately, commits appear to be completely disconnected from PRs in DevOps repos – clicking a commit navigates away from the PR, and comments left on commits do not even show in PRs.
Everything else about DevOps PRs appears to be on-par or better than Github PRs, well done! But the commit-at-a-time workflow is the key feature for my team.
Thanks for this new experience.
I detect a missing part with this new interface : The by-pass, to merge this PR without respect policies
Override branch policies and enable merge
yes I’m also missing this. As an admin I need to be able to override the policies occasionally to resolve issues. Hope this is fixed before official release.
I used to have problem scrolling through file and adding comments when on mobile. In fact I was having it just this morning, and now I can scroll and comment without any issues. This team is great. Love the responsive UI, vivid UX, and useful features. Great job team. 🙂
In the quick view section, next to the Search bar, I could see all my open PRs, from all repos, now I can’t see all, but only those under the current Repo. But when I click view more, and it opens a new page, and there I can see all PRs. A few weeks ago, I could see all PRs under this tab.
The new look is not auto-assigning work items to the PR when the task number is on the commit message. This was working before and after I switched to the new experience it stop working
FYI, this was mentioned further up in the comments (see here). You’re not alone—I’m one of the commenters. 🙂
I’ve filled out the survey that’s been linked to in the comments and gave my feedback already, but I just thought of another suggestion and now I can’t fill out the survey again.
I would like the ability to disable or hide (at a branch policy level or at an organizational level) the “Cherry-pick” option that becomes available once a PR is completed. In our organization, we use a branching model where our release branches always eventually get merged back into our development branch. Cherry-picking creates copies of commit IDs, and doesn’t merge the original commit ID. Meanwhile work might continue on those files in the development branch, so when the release branch finally gets merged back, conflicts arise because those original commit IDs were never resolved (only their copies were).
99% of those conflicts were all attributed to cherry-picking PRs, and as soon as we put a moratorium on cherry-picking the problem went away. However, I’d rather not have to keep educating the team on why they shouldn’t click that button, and just remove the button so they can’t click it.
My understanding is Microsoft doesn’t do that model of branching, so it makes sense that cherry-picking would be quite natural and a big convenience for them, and a sensible default (in fact, I believe there’s a plug-in that allows multiple cherry-picking at once, which sounds insane to me), but the system should be flexible enough to support different workflows.
Hi!!!! Is it possible to make the association of a work item to a pull request mandatory?