Azure DevOps Server 2020.1 新增功能 (TFS)

1. 概述

自2005年开始，微软在VSS的基础上发布了TFS(2019年开始更名为Azure DevOps Server)的第一个版本TFS 2005,后续陆续发布了2008/2010/2012/2013/2015/2017/2018/2019/2020，每个版本都会给用户带来令人兴奋的功能。

同样，微软即将发布的Azure DevOps Server 2020 Update 1也为我们带来了一波与软件研发项目管理最新的功能，本文下面的内容就摘录这个最新版本的主要功能。

Boards

State transition restriction rules

We continue to close the feature parity gap between hosted XML and the inherited process model. This
new work item type rule lets you restrict work items from being moved from one state to another. For
example, you can restrict Bugs from going from New to Resolved. Instead, they must go from New –>
Active -> Resolved
You can also create a rule to restrict state transitions by group membership. For example, only users in
the “Approvers” group can move user stories from New -> Approved.

Copy work item to copy children

One of the top requested features for Azure Boards is the ability to copy a work item that also copies the
child work items. We added a new option to "Include child work items" to the copy work item dialog.
When selected, this option will copy the work item and copy all child work items (up to 100).

Improved rules for activated and resolved fields

Up until now, the rules for Activated By, Activated Date, Resolved By, and Resolved Date have been a
mystery. They are only set for system work item types and are specific to the state value of "Active" and
"Resolved". We've changed the logic so that these rules are no longer for a specific state. Instead, they
are triggered by the category (state category) that the state resides in. For example, let's say you have a
custom state of "Needs Testing" in the Resolved category. When the work item changes from "Active" to
"Needs Testing", the Resolved By and Resolved Date rules are triggered.
This allows customers to create any custom state values and still generate the Activated By, Activated
Date, Resolved By, and Resolved Date fields, without the need to use custom rules.

Stakeholders can move work items across board columns

Stakeholders have always been able to change the state of work items. But when they go to the Kanban
board, they're unable to move the work items from one column to another. Instead, Stakeholders would
have to open each work item, one at a time, and update the state value. This has long been a pain point
for customers, and we're happy to announce that you can now move work items across board columns.

System work item types on backlogs and boards

Now you can add a system work item type to the backlog level of choice. Historically these work item
types have only been available from queries.
Process Work Item Type
Agile Issue
Scrum Impediment
CMMI Change Request
Issue
Review
Risk
Adding a system work item type to a backlog level is simple. Just go into your custom process and
click the Backlog Levels tab. Select your backlog level of choice (example: Requirements Backlog)
and choose the edit option. Then add the work item type.

Audit logging event

We have added a new event to the audit logs to help customers better track process related changes.
An event will be logged whenever the values on a picklist are changed. Changes to picklist fields are
usually the most common changes made to a process. With this new event, collection admins can better
track when and who made changes to those fields.

Azure Boards GitHub app repo limit raised

The repo limit for the Azure Boards application in the GitHub marketplace has been increased from 100
to 250.

Customize work item state when pull request is merged

Not all workflows are the same. Some customers want to close out their related work items when a Pull
Request is completed. Others want to set the work items to another state to be validated before closing.
We should allow for both.
We have a new feature that allows you to set the work items to the desired state when the pull request
is merged and completed. To do this, we scan the pull request description and look for the state value
followed by the #mention of the work item(s). In this example, we are setting two user stories to
Resolved and closing two tasks.

Link your work item to builds in another project

You can now easily track your build dependencies across project just by linking your work item to a
Build, Found in build, or Integrated in build.

Editing description (help text) on system fields

You have always been able to edit the description of custom fields. But for system fields like priority,
severity, and activity, the description was not editable. This was a feature gap between the Hosted XML
and Inherited that prevented some customers from migrating to the Inherited model. You can now edit
the description on system fields. The edited value will only affect that field in the process and for that
work item type. This gives you the flexibility to have different descriptions for the same field on different
work item types.

Customize work item state when pull request is merged

Pull requests often refer to multiple work items. When you create or update a pull request, you may
want to close some of them, resolve some of them, and keep the rest open. You can now use comments
such as the ones shown in the figure below to accomplish that. See documentation for more details.

Parent field on the task board

Due to popular request, you can now add the Parent field to both the child and parent cards on the Task
Board.

Removing "Assigned To" rule on Bug work item type

There are several hidden system rules across all the different work item types in Agile, Scrum, and
CMMI. These rules have existed for over a decade and have generally worked fine without any
complaints. However, there are a couple of rules that have run out their welcome. One rule in particular
has caused a lot of pain for new and existing customers and we have decided it was time to remove it.
This rule exists on the Bug work item type in the Agile process.
"Set the Assigned value to Created By when state is changed to Resolved"
We received a lot of your feedback about this rule. In response, we went ahead and removed this rule
from the Bug work item type in the Agile process. This change will affect every project using an inherited
Agile or a customized inherited Agile process. For those customers who like and depend on this current
rule, please see our blog post on the steps you can take to re-add the rule in using custom rules.

Removed items on the Work Items page

The Work Items page is a great place to quickly find items you created or that are assigned to you,
amongst other things. It provides several personalized pivots and filters. One of the top complaints for
the "Assigned to me&#