Azure DevOps Server 2019 Cookbook（Second Edition）

上QQ阅读APP看书，第一时间看更新

How it works...

With the branch policies in place, the master branch is now fully protected. The only way to push changes to the master branch is by first making the changes in another branch and then raising a pull request to trigger the change-acceptance workflow. From one of the existing user stories in the work item hub, choose to create a new branch. By creating a new branch from a work item, that work item automatically gets linked to the branch. You can also include more than one work item with a branch as part of the create workflow:

Prefix / in the name when creating the branch to make a folder for the branch to go in. In the preceding example, the branch will go in the sprint1 folder. This is a great way to organize branches in busy environments.

With the newly created branch selected in the web portal, edit the HomeController.cs file to include the following code snippet and commit the changes to the branch. In the image below you'll see that after editing the file, you can directly commit the changes by clicking the commit button.

The file path control in team portal supports search. Start typing Home in the file path to see all the files in your Git repository under that directory starting with these letters. They will show up in the file path search results dropdown.

The code editor in web portal has several new features in Azure DevOps Server 2018, such as support for bracket matching and toggle white space, and so on. You can load the command palette by pressing F1. Among many other new options, you can now toggle the file using a file mini-map, collapse and expand, as well as other standard operations.

To push these changes from the new branch into the master branch, create a pull request from the pull request view. Select the new branch as the source and the master as the target branch. The new pull request form supports markdown, so you can add the description using the markdown syntax. The description window also supports @ mentions and # to link work items:

The pull request will be created; the overview page summarizes the changes and the status of the policies. The Files tab shows you a list of changes, along with the difference between the previous and the current versions. Any updates that are pushed to the code files will show up in the updates tab, and a list of all the commits is shown under the Commits tab:

Open the Files tab: this view supports code comments at the line level, file level, and overall. The comments support both @ for mentions and # to link work items, and the text supports markdown syntax:

The code comments are persisted in the pull request workflow; the code comments support multiple iterations of reviews and work well with nested responses. The reviewer policy allows for a code review workflow as part of the change acceptance. This is a great way for the team to collaborate on any code changes being pushed into the master branch. When the required number of reviewers approve the pull request, it can be completed. You can also mark the pull request to auto-complete after your review. This auto-completes the pull requests once all the policies have been successfully compiled to.