作者：徐子岩 Shaun Xu
研发自动化产品 PingCode Flow 曾经上线将近半年的工夫。在这期间，咱们很快乐的看到越来越多的研发团队试用、承受并喜爱上这款产品。从目前的后盾监控数据看，咱们的客户在 PingCode Flow 中共创立了将近 2500 条规定，均匀每天执行规定近 3500 次。如果咱们做一个简略的计算，假如主动执行的一条规定相当于原先 30 秒的手工操作，那么这就意味着，每天 PingCode Flow 帮客户节俭了将近 30 个小时的工作量。
随着对 PingCode Flow 的认可度逐步提高，咱们在和客户沟通的时候也发现，大家对于如何在本人的团队中创立适合的规定存在着一些艰难。尽管 PingCode Flow 内置了将近 30 个模板，涵盖了从软件开发、项目管理，到 DevOps、团队治理等诸多畛域，然而一个实在的研发团队如何应用 PingCode Flow，哪些规定适宜，以及如何调整规定的具体步骤，对于客户来说还是有一些难度。
因而，咱们心愿通过这篇文章，分享一下咱们 PingCode 研发团队本人在应用哪些规定，为什么应用，以及带来的成果和收益。心愿可能给读者提供一些思路和借鉴。
接下来，我将会分为研发治理、高效沟通、DevOps 和人员治理四个方面，介绍咱们正在应用的局部规定。
研发治理
研发治理蕴含了研发团队在日常开发过程中的一些流程和要求。之前为了标准团队，咱们须要制订具体的开发手册，为新退出的员工进行培训；在日常工作中，研发组长还要随时查看并揭示团队成员恪守。除此之外，在标准和流程有更新的时候，还须要同步到手册中，培训并时刻揭示成员新的要求。所有的这些工作都极大地占用了一线管理者和团队成员的工夫和精力。接下来，我将介绍几个与研发治理相干的规定。
无人负责的工作项变为「进行中」后主动设置负责人
咱们心愿在研发过程中，每一项工作都有一个明确的负责人。这样不仅可能明确责任，同时也能主观的展现出目前工作的停顿情况，成员的工作负荷以及团队的人员配置是否正当。然而，无论是因为成员的大意，还是因为我的项目紧工作重，常常会呈现工作项被设置为「进行中」了，然而并没有同时支付负责人。为此，咱们创立了这个规定。
首先，规定在工作项状态被设置为「进行中」后触发。
随后，判断当前工作项的负责人是不是处在未设置状态。
最初，将工作项的负责人设置为规定的触发者，也就是最开始变更了工作项状态的那个成员。
通过如此简略的三个步骤，咱们就完满的解决了「团队成员遗记设置负责人」这个问题。无需员工手册，也无需培训。
主动设置工作项所属迭代
与上一个场景相似，在麻利开发的过程中，咱们不可避免的在进行中的迭代内长期退出一些新的用户故事或缺点。这些工作项可能是长期创立的，或者从需要池调整来的。那么在团队成员开始工作的时候，须要确保它的迭代属性被设置到以后迭代中，否则就会导致 Scrum Master 无奈精确理解以后迭代的工作内容，在 Sprint Review 会议中很有可能漏掉这个工作。
因而咱们创立了这个规定，在工作项状态被设置为「进行中」后，查看其迭代属性是否为空。
如果为空的话，就将这个工作项退出到所属我的项目的以后迭代中。
高效沟通
在考查研发团队工作效率的时候，咱们往往将关注点都放在了研发流程和标准上。诚然，流程和标准是进步研发效力的次要路径，然而团队内以及团队间的沟通合作是否高效，也大大影响了研发人员的工作效率。而且，沟通的老本不仅仅体现在沟通所需的工夫自身，它还蕴含了因为沟通不及时不正确导致的期待、谬误和返工问题。而这些工夫上的耗损往往没有失去足够的器重。
PingCode 研发团队目前 8 个开发小组，组内的沟通自不必说，各个小组之间的沟通，研发团队与运维团队的沟通，以及产研与营销的线的沟通都十分的频繁。如何可能及时、疾速且正确的同步工作进度、后果，这不仅影响产研的效率，也影响着客户满意度和公司营收。
上面的几个规定就是联合咱们本身的需要，重点解决团队内以及跨团队的沟通问题。
告诉被阻塞的工作项
这个规定应该是自上线以来，团队成员反馈最为有用的规定之一了。它要解决的场景非常简单。研发过程中，不可避免的有工作间的从来关系，也就是说，某些工作必须期待其它工作的实现后能力开始。具体的，能够通过 PingCode Agile 中对于工作项的「阻塞」和「被阻塞」关联关系来展。
当一个工作项状态发生变化，特地是曾经实现后，须要告诉到被阻塞的工作项负责人，让他们尽快开始后续的工作。之前咱们团队的要求是，当团队成员实现一个工作项后，要检查一下有没有被阻塞的其它工作项。如果有的话，须要告诉（口头或者发评论）到对应的负责人。然而在大家缓和工作的时候，总会无意间遗记告诉，或者漏掉了某个负责人，导致开发工夫无端被节约。开发组长和 Scrum Master 还须要定期检查跟进状态，十分费时费力。
针对这个问题，咱们创立了如下的一条规定。当工作项状态变动后，PingCode Flow 会主动查看所有被其阻塞的工作项。
而后，向这些工作项发送一条评论，告知负责人和关注者，阻塞的工作项状态曾经发生变化了。
启用了这条规定后，团队成员无需手动揭示后续工作的负责人，团队管理者也不必花工夫每天查看相干的进度。团队的合作和沟通都会主动的、及时的，并且准确无误的执行。
主动为客户提交的缺点和需要设置产品负责人关注
在 PingCode 研发团队，咱们非常重视最终客户和用户的应用反馈，包含缺点、产品倡议和产品需要。个别的，客户的声音会优先传递给咱们的客户胜利部门，再由客户胜利部门加工整顿，在名为「PingCode Bugs」的我的项目里创立工作项进行跟踪。
之前，客户胜利共事创立工作项时，须要依据对应的子产品，设置上对应的产品负责人为关注者。然而有的时候会遗记设置，有的时候会设置到谬误的产品经理。这就造成了客户的诉求无奈及时反馈，影响咱们最终的客户满意度。而接下来介绍的这个规定，就是为了解决此问题而创立的。
首先，当「PingCode Bugs 我的项目」中有缺点或用户故事被创立时，会触发这个规定。
而后，咱们针对这个工作项题目进行判断。当蕴含某个子产品名字的时候，就设置这个子产品的产品负责人为关注者。比方当题目蕴含「Agile」，就会退出「PingCode Agile」的产品负责人；蕴含「Wiki」就退出「PingCode Wiki」的产品负责人。以此类推。
DevOps
研发团队在流程化之外，还有大量的工程化工作，也就是咱们常说的 DevOps 相干的工作。依赖于 PingCode Flow 对外部零碎的反对，咱们团队将麻利开发与代码托管、流水线联合在一起，实现了研发自动化工作流。这里限于篇幅的关系，咱们仅以 Code Review 和继续构建为例，简略介绍一下 PingCode Flow 如何反对 DevOps。
基于 GitHub Pull Request 的 Code Review
Code Review 是每一个谋求品质的研发团队必不可少的工作。然而，如何高效的执行是每个团队面临的一大挑战。一方面，大家都认同 Code Review 的重要性，另一方面，又放心 Code Review 会不会给开发工作削减大量的工夫，又或让 Code Review 流于形式。咱们 PingCode 研发线在 2019 年就曾经实现了全员的强制 Code Review 制度，任何产品代码都必须通过至多一名组员评审能力被合并到主开发分支。
然而，在具体实际过程中，流程的确很繁琐。
- 工程师在 PingCode Agile 上支付某个用户故事，设置负责人。
- 在 GitHub 下面依照工作项编号创立对应的开发分支。
- 返回 PingCode Agile，设置工作项状态为「进行中」，开发、测试、提交代码。
- 在 GitHub 上基于分支创立 Pull Request。
- 在 Worktile 的对应群组中揭示相干人员进行 Pull Request Review。
- 评审人员收到 Worktile 音讯后，进入 GitHub 进行评审。
- 评审结束后，评审人在 Worktile 上告诉工作项负责人评审通过，能够合并。
- 负责人收到 Worktile 音讯后，进入 GitHub 合并分支。
- 负责人返回 PingCode Agile，将工作项设置为「已实现」。
能够看到，为了实现一个 Code Review 流程，工程师和评审人须要频繁的在代码托管平台（GitHub）、麻利工具（PingCode）和 IM 工具（Worktile）上切换，效率极其低下。正因为如此，咱们剖析了整个流程后，找到了一些能够自动化执行的点，创立了几个规定配合应用，最终简化流程。
创立 GitHub Branch 后主动开始工作项
首先咱们解决的是在开始工作时，GitHub Branch 和 PingCode Agile 工作项的联动问题。工程师在 GitHub 上创立的分支后，PingCode Flow 会主动提取分支名称中的编号信息，找到对应的工作项。
而后，为工作项增加一条评论，提醒对应的分支曾经创立结束。
同时，将工作项的状态从「关上」变为「进行中」。
创立 GitHub Pull Request 后告诉评审人
接下来，咱们着手改良 Code Review 中负责人和评审人的沟通问题。咱们心愿在 GitHub Pull Request 被创立后，可能主动告诉对应的评审人。首先，在 GitHub Pull Request 被创立后触发一条规定。
接下来，从 GitHub Pull Request 的题目和源分支名中提取对应的工作项。
最初，通过 Pull Request 外面题目提取须要的评审人，发送评论，揭示他们有一个 Code Review 须要评审。
这样，当有 Pull Request 被创立时，评审人就会收到相应的揭示，点击链接就能够间接跳转的 GitHub Pull Request 页面进行评审工作了。
主动发送 GitHub Pull Request Review 状态变更信息
在上一步中，评审人看到 Code Review 告诉后，点击链接实现评审。当 Pull Request Review 的状态由 Pending 变为 Approved、或者 Reject 后，通过这条规定就能够主动揭示 Pull Request 的作者（也就是对应工作项的负责人），及时的批改 Code Review 发现的问题，或者合并曾经评审通过的代码。
收到的告诉音讯是这样的。
合并 GitHub Pull Request 后主动实现工作项
最初，当负责人会 GitHub 上合并以后 Pull Request 时，咱们心愿对应的工作项可能主动设置为「已实现」。当 GitHub Pull Request 的状态变为「Merged」后，会触发这条规定。
其次，与之前的规定相似，通过 Pull Request 名或者源分支名提取到对应的工作项。
最初，在给工作项发送评论的同时，如果将状态由「Code Review」设置为「已实现」。
这样，咱们通过上述四个规定，简化了研发团队在 Code Review 过程中的操作流程，使沟通更加的顺畅，同时让工作项的状态可能及时反映实在的开发状态。
相比于之前，简化后的流程是这样的。
- 工程师在 PingCode Agile 上支付某个用户故事，设置负责人。
- 在 GitHub 下面依照工作项编号创立对应的开发分支，开发、测试、提交代码。PingCode Flow 主动设置工作项为「进行中」，
- 在 GitHub 上基于分支创立 Pull Request。PingCode Flow 主动揭示评审人。
- 评审人员收到揭示后，进入 GitHub 进行评审。评审后果会主动告诉工作项负责人。
- 负责人收到评审后果的告诉后，进入 GitHub 合并分支。PingCode Flow 主动设置工作项为「已实现」。
告诉我的项目成员 Jenkins 的构建后果
PingCode 研发线应用 Jenkins 作为继续集成和继续部署工具，利用 Jenkins 上定义的上百条流水线，咱们实现了从代码提交到单元测试、集成测试、灰度公布以及 Alpha、Beta、RC、Product 四个环境的主动部署能力。
为了实现 DevOps 第二工作法，咱们须要将继续集成和继续部署的后果实时的反馈给开发团队。这能够通过 PingCode Flow 中的 Jenkins 连接器去实现。
具体的，通过 Jenkins 连接器中的「变更 Jenkins 构建状态」触发器来获取 Jenkins Job 的构建后果。当一个 Job 状态发生变化了（无论是胜利还是失败），就会触发这条规定。并且，运维组的共事会将此触发器的 Webhook 地址配置到对应的 Jenkins Job 上。
而后，针对 Jenkins 上配置的流水线，咱们找到对应的 PingCode Agile 我的项目。以以后规定为例，运维组配置了 PingCode Flow CI 这条流水线，因而咱们接下来间接获取 Flow 这个我的项目。
最初，将 Jenkins 构建后果通过 PingCode 告诉发送给我的项目成员。
这样当流水线执行结束后，我的项目成员都会收到如下的音讯。
这样，当流水线执行出现异常，或者构建失败时，所有成员都会第一工夫收到告诉并进行解决。最大限度了保障了 DevOps 工作流的顺畅。
人员治理
随着研发团队的扩充，一个项目组在平时工作中须要拜访的资源也会变多。以咱们 PingCode 研发线为例，我的项目成员须要拜访对应子产品的需要、工作项和迭代信息，也就是 PingCode Agile 中的我的项目；子产品的文档，也就是 PingCode Wiki 的知识库。整个研发线成员还须要可能拜访一些公共的我的项目和知识库，譬如用于收集缺点和客户需要的我的项目，研发治理相干的知识库等。在别的团队，可能研发和测试工程师还要可能拜访对应的测试库。
每当团队迎来认为新成员的时候，团队的负责人须要将其退出到上述的我的项目、测试库、知识库中。尽管每次的操作工夫可能不会太久，然而却是一个繁琐的工作，而且一旦有错漏，会造成新成员无奈在第一工夫取得信息，甚至对团队和组织的正规性产生狐疑。
咱们 PingCode 研发线也受困于上述的问题很久。然而随着 PingCode Flow 的上线，终于能够应用一条规定来实现下面所有的操作。
新成员主动退出我的项目、知识库等
首先通过「成员退出用户组」这个触发器来启动规定。每当新成员退出咱们研发部，HR 共事会设置其在 PingCode 中的用户组，就会触发这个规定。
随后咱们通过多个分支，来别离解决成员被退出到不同用户组后，增加到不同我的项目和知识库的操作。首先是所有组员都会拜访的资源，也就是当成员被退出到「研发组」这个大用户组后，会退出到研发线共有的我的项目和知识库。
而后咱们针对不同的子产品组，创立不同的分支。判断成员所在的用户组，退出到对应的我的项目和知识库中。比方上面是 PingCode Flow 组和运维组新成员退出的时候。
以上就是咱们 PingCode 研发团队本人在应用的局部自动化规定。除此之外，咱们还有很多其它的规定来辅助日常的开发工作。
譬如
- 在工作项设置为「已实现」后告诉设计师和产品经理进行验收。
- 运维组创立用户故事时主动设置关注人。
- 进行中的迭代内退出新的用户故事时告诉 Scrum Master。
- 同步关联关系为「反复」的工作项状态。
- ……
其实这些规定并不是咱们一次性设计并投入使用的。从 PingCode Flow 内测开始时的几条规定，随着团队成员的一直适应，以及咱们逐渐挖掘可能的场景，才倒退到目前将近 30 条规定。因而咱们倡议，研发自动化的引入肯定要循序渐进，遵循
- 发现问题
- 定位起因
- 设计规定
- 小范畴试验
- 收集反馈
- 调整规定
- 大范畴应用
这样的逻辑。让团队成员尽快感触到自动化的益处，逐渐适应这样的规定，进而提出本人的想法和需要，一直迭代，最终进步工作效率，晋升研发效力。