Azure DevOps Server （TFS）定制工作流（集成模板）

1. 基本概念

1.1 概述

从Azure DevOps Server 2019 开始，微软在产品中增加了一种名称为“继承模板”（Inherited Process）的工作项模板；相比传统的的XML模板，继承模板在使用上为用户提供了非常便捷的定制功能，大幅降低了用户定制工作项需要掌握的知识门槛；在使用集成模板时，我们可以了解到下面几个典型的特点：

可视化定制：
相比传统的XML工作项模板，用户可以使用网页浏览器，使用鼠标点击和拖拽就可以快速定制一个符合企业需求的工作项流程；用户不在需要去了解各种隐藏的、晦涩的工作项XML节点；
项目见共享
定制的集成模板，可以在所有团队项目中实现共享；就是说，当工作项模板发生变化时，所有应用这个模板的团队项目流程会马上发生变化；当然，我们也可以项目XML模板一样，为每个团队项目定制一个工作项模板；
系统模板和定制模板
DevOps Server中存在两种类型的集成模板，一种是系统模板，另一种的定制的集成模板；微软会定期更新系统模板，用户不能更改系统模板；但是用户以系统模板为基础，定制一个继承系统模板所有特征的、符合企业需求的工作项模板，这也是集成模板命名的来由。

在工作项过程模板中，工作项流程（Work Flow）是非常重要的一个功能，也是定制过程中比较复杂的一个环节。从新建到关闭（或完成），每种工作项类型都通过流程状态来跟踪工作项的生命周期；为了满足企业的业务需求，我们常常需要定制工作项的流程，来实现各种审核和流转；例如，在跟踪Bug时，我们希望在系统默认的流程中新增一个“会诊”的状态；在敏捷开发的用户故事中，我们希望增加一个“设计”的状态。

在本文中，我主要为大家介绍如何在工作项中实现工作项流程的定制，实现工作项流程的管理和设计，文章中的主要内容包括：

系统支持的工作项流程定制场景
工作项流程定制对看板的影响
工作项流程定制的操作步骤
添加和移除定制的流程状
隐藏和显示系统默认的流程状态
查看流程状态的图形设计

注意：
本文涉及的内容都是基于Azure` DevOps Server 2019以及之后的新版本，如果你需要了解旧版本的工作项定制，需要查看微软XML工作项定制的相关文档 https://docs.microsoft.com/en-us/azure/devops/reference/on-premises-xml-process-model?view=azure-devops-2020&viewFallbackFrom=azure-devops&WT.mc_id=DT-MVP-5001330

1.2. 可以实现定制的功能

通过添加新的工作项状态，或者隐藏系统默认的流程状态，可以实现对任何工作项的流程定制。
系统默认的状态也称为“集成的状态”；根据我们选择的流程模板类型（基本、敏捷、CMMI、Scrum），模板中的集成状态是不同的。
任何一个工作项类型中，工作项流程主要包含下面两个操作：

在任意状态之间的前进和后退转换
状态切换是的原因设置
例如，在基本模板中，问题工作项的的状态分为三个：待处理、正在进行、完成（也是我们常见的TO Do, Doing, Done），他们的流程状态图如下：

我们新增或修改一个流程状态时，必须确保流程状态符合下面的规则

流程状态至少要包含两种类型：已建议、已完成；
每个状态类型中至少需要有一种状态，就是说至少要有两个状态；当然，如果只有一个状态，那就称不上流程了
由于系统设计的原因，每个工作项的流程状态最多为32个；实际上我们也不太可能定制一个包含了32个状态的流程

1.3. 不能实现定制的功能

在定制工作项流程中，对于不能实现的功能，要做到心知肚明，否则研究了半月后才发现系统根本就不支持你的需求，等于白费劲了，目前Azure DevOps Server还不支持的功能包括：

不能修改系统默认的状态，只能显示或隐藏系统默认的状态；对于新增的状态，可以实定制，例如修改名称、颜色、类型等
对已完成类型的状态，只能有一个，不能保存多个；在已完成类型中添加一个状态后，其他已经存在的状态就会被隐藏或移除
新建后的状态，不能修改名称，只能修改它的颜色或者类型
不能对状态指定原因（在传统的XML流程模板中，这是非常常见的定制）；对于定制的状态，单用户变换状态时，可以自己修改原因，而不是从原因选项中挑选一个原因；
在页面布局中，状态和原因的位置是不能定制的；

1.4. 流程状态的排序

在老版本的TFS系统中，状态的是按照字母顺序来排列的；在定制工作项中，如果要实现用户期望的排序，我们经常在状态前面填写序号，例如01新建、02审核、03关闭等；
在集成模板中，在同一类型中，状态的排序可以按照用户定制的顺序来排列；我们可以在定制状态时，自主调整状态的位置；
对于状态的类型，系统有其固有的排列顺序，例如已建议总是排在最前面，已完成类型的状态总是排在最后面。

1.5. 流程状态改变对工作项的影响

当我们修改一个已经存在工作项的流程状态，必须要考虑流程状态调整对于已经存在的工作项的影响：

如果我们修改的工作项在看板中，我们需要同步调整看板的列
修改流程模板中的状态，不会修改工作项的任何字段，已经存在的工作项的状态不会自动修改，但是状态已经是不合规范的选项，当用户修改工作项的其他信息时间，必须首先修改状态，否则系统不允许你保存更改。

2. 定制流程状态

2.1 前提条件

在定制流程状态之前，需要对Azure DevOps Server的工作项模板的基本知识做一个全面的了解，可以参考下面微软的官方文档：https://docs.microsoft.com/en-us/azure/devops/boards/configure-customize?view=azure-devops&tabs=agile-process?WT.mc_id=DT-MVP-5001330
你需要具备团队项目集合的权限
或者，你需要具备流程模板的管理权限，如下图：

2.2 打开流程模板

在团队项目集合首页，点击“集合设置”

选择进程

注意，如果在这里，你看不到进程菜单，可能你还在使用TFS 2018或者更旧的版本；那么你只能使用XML模板实现工作项流程的定制。
由于集成模板的共享特征，当流程模板发生变化时，所有应用这个模板的团队项目都会自动发生变化；因此，如果你需要做大量的流程模板改定，我们建议你先创建一个集成模板，并用这个集成模板新建一个测试用途的团队项目，用于验证自己的定制是否符合需求，避免定制对现有工作流程产生影响。