本文由 简悦SimpRead 转码，原文地址 about.gitlab.com
深入了解Phabricator的功能，促使GitLab围绕automobile建立新的工具......。
创新的发生往往是因为竞争激发了新的想法。我们解读了Phabricator是如何激发GitLab增加新功能的。
时光倒流，Phabricator究竟是什么？Phabricator建立在基于网络的应用程序的概念之上，它使开发人员能够通过代码审查、存储库浏览器、变更监控、错误跟踪和维基来进行协作。2021年5月29日，Phabricator的维护者和赞助商Phacility宣布终结生命，停止维护Phabricator。
GitLab的联合创始人兼首席执行官Sid Sijbrandij在HackerNews上对Phabricator给予了肯定。
在我创办GitLab时，Phabricator给了我很大的启发。它现在已经关闭了。它的许多功能都领先于它的时代，而且该产品有很多幽默感。为了向它致敬，我们是否应该增加Clowcoptarize作为一种合并方式？这将是一个在GitLab 14.0中引入的可选选项。
这让我很好奇：Sid所说的这些灵感是什么？让我们一起深入了解GitLab的历史，看看我们能学到什么。
Tip: 在GitLab文档的功能中经常有一个版本历史框。你可以利用问题的URL来深入了解功能建议、讨论等。
评审工作流程
一个典型的工程工作流程是这样的。工程经理将一个新问题作为任务分配给一个开发人员。开发人员在他们喜欢的IDE中工作--本地的VS Code或Gitpod云环境中。变化发生在Git的一个新特性分支中，该分支被推送到远程Git服务器上进行协作。
这个 Git 分支还没有准备好，隐藏在一个可能很长的分支列表中。为了更好地跟踪他们的特性分支，开发者可以将分支名称或URL复制粘贴到相关问题中--我10年前就这么做了。Phabricator中的 "diff链接到审查任务 "的概念，以及GitLab中的 "提交与合并请求相链接的Git分支 "的概念还没有被发明。
Phabricator启发GitLab创建了一个用于审查的默认工作流。Phabricator的工作流程使审查更具有主导性，并在审查通过后将所有修改压制在一个提交中。自动压扁提交的做法有好处也有坏处。压扁提交可能意味着失去审查历史中的信息，并产生更多的讨论。根据应用程序的架构、变化频率和调试要求，这可能是一件好事，也可能是一件坏事。GitLab允许你在合并一个MR之前选择压制提交，或者指定围绕压制提交的默认项目设置。
Phabricator将MR（或他们所谓的 "差异任务"）作为跟踪变更和审查历史的唯一真理来源。我们觉得这是个好主意，并在GitLab的MR中复制了Phabricator中的 "差异任务 "的过程。GitLab版本的一个主要优点是，在问题和史诗中发生的协作和讨论，即使在变更被合并后仍然可用。
MR草案（或 "差异任务"）。
很多时候，当在GitLab中创建一个MR时，该分支需要额外的工作才能准备好被合并。Phabricator在2013年为 "diff任务 "引入了正式的 "草案"/"尚未准备好审查 "状态，这有助于跟踪这种状态下的工作。GitLab在2016年增加了WIP MRs，然后我们在2020年将其更名为草案合并请求。虽然 "WIP "对某些人来说可能是有意义的，但首字母缩写会把新人排除在外。我们发现Draft更容易被识别。为了避免混淆，GitLab 废除了WIP，转而使用草案合并请求。
在MR中保留历史，以便将来调试
在GitLab中的提交历史中加入了与MR和相应的Git审查历史的链接，使之更加丰富。在生产中出现紧急情况时，把所有东西都记录下来，可以更快地进行研究和调试。
GitLab在合并提交信息中存储了MR的短网址<namespace>/<project>!1234。查看一个Kubernetes代理的演示项目的历史，看看合并提交是如何呈现的。
GitLab的提交历史包括指向MR的链接。
这些原始信息保存在Git仓库中，而MR本身则保存在GitLab的数据库后端。你可以通过克隆一个仓库并使用此命令检查历史记录来验证这一点。
MR元数据包含在
git log命令的输出中。
MRs中的代码覆盖率
代码覆盖率报告提供了关于单元测试覆盖了多少行源代码的洞察力。达到100%的测试覆盖率是一个开发者的神话--可视化的减少或增加可以帮助监测代码质量的趋势。Phabricator实现了对各种语言的单元测试引擎和解析输出的支持，例如在Golang。
由于有许多不同的语言和报告输出格式，将代码覆盖率报告整合到GitLab MRs中是一个挑战。GitLab在2016年推出了代码覆盖率报告的第一次迭代，它用CI/CD作业生成报告，并使用GitLab页面来发布HTML报告。
在第一次迭代中，测试覆盖率是用CI/CD作业输出的正则表达式来解析的，在项目设置中指定或在CI/CD作业配置中使用coverage关键字。我们可以在MR widget内的作业视图中看到，并作为项目的覆盖率徽章。通过导航到 "Analytics > Repository "查看测试覆盖率历史。
GitLab项目中的测试覆盖率徽章。
JUnit XML测试报告作为通用格式规范被引入，并作为MR widget in 2018添加。测试报告在后台运行，使用CI/CD工件将XML报告从运行器上传到服务器，其中MR/管道视图在一个标签中可视化覆盖率报告。
通用的JUnit集成也有助于对单元测试的定制请求，更新CLI命令，或改变覆盖率报告输出来解析。GitLab提供CI/CD模板示例
GitLab缺少的是MR diffs里面的内联代码覆盖备注。大约五年后，Sid最初提出的内联代码覆盖率注释才得以实现。2020年，内联代码覆盖率注释在GitLab 13.5中发布。
内联代码覆盖如何在GitLab中工作。
请查看本MR练习验证测试覆盖率。请务必选择内联差异视图。
自动化工作流程和集成CI
Phabricator提供了Herald作为一个自动任务运行器和规则引擎来监听变化。Herald也可用于确保受保护的分支和批准规则，以在开发工作流中执行强大的权限模型。在这篇HackerNews 2016年的帖子中还有更多的例子，不知为何，我觉得自己像个探险家，以类似的方式看到了许多GitLab的伟大功能。🦊
GitLab CI/CD pipeline schedules让我想起了任务运行器，类似于webhooks和REST API从CI/CD作业中获得工具。管道时间表也是定期再生缓存和重建云原生部署的容器镜像的一个好方法。
Harbormaster是Phabricator的CI集成。它不是由DevOps堆栈中的多个工具构建而成，而是完全集成在产品中。
GitLab CI的第一个版本创建于2012年11月。2015年，GitLab团队的一名成员提出了将SCM与CI相结合的想法，一体化的DevOps平台诞生了。内置的CI/CD激发了更多的功能，促进了更好的共同创新。新的管道编辑器只是在GitLab中配置CI/CD管道的精简方式的一个例子。
让我们回到2017年，看看我们如何使用GKE在GitLab中把一个想法带入生产。
问题管理的工作板
工作需要被组织起来。Phabricator以一个板块引领潮流，它允许用户过滤任务，并为规划和项目管理提供更详细的视图。
Phabricator工作板内部。
GitLab用户会认识到Phabricator的工作板和GitLab问题板之间的相似外观。在GitLab 14.1中，我们在现有的史诗跟踪和标签的基础上创建了史诗板，以保持团队的组织性和衡量进度。
在Phabricator中，用户可以在各栏之间拖放，从而自动改变某项任务的工作状态。这一功能启发了GitLab中的板块，通过在列之间拖放，自动改变定义的工作流程中的标签。用户可以通过范围内的标签更深入地在工作流状态之间切换。
工作流程::设计工作流程::计划分解。工作流程::准备开发。工作流程::开发中。工作流::验证
GitLab工程手册记录了不同的工作流程。
看看GitLab中的Epic板。
把它放在一起
在Phabricator中，一个处于 "审查 "状态的差异任务（在GitLab中是MRs）与另一个指定需求的任务相连接。用户体验需要明确，以便能够访问和理解差异之间的关系。除非有必要，用户不应该手动浏览。变更审查的上下文定义了与标签、状态、依赖问题、差异任务（MRs）等的可能链接。
GitLab链接相关问题。如果一个问题在MR中被提及，或者反之亦然，GitLab会自动链接它们。用户还可以选择一旦有变化被合并，问题就自动关闭。阅读2016年的一篇博文，了解更多关于问题和MR在GitLab中是如何相互关联的。
GitLab中的链接问题和相关的MR。
用户体验工作具有挑战性，我们不断迭代以改善GitLab的工作流程。例如，在GitLab 13.8中，我们减少了从MR中下载CI/CD工作工件的点击次数。
我们是否错过了Phabricator启发的一个功能？
在写这篇博文时，我的研究发现了更多的宝藏。例如，我在HN线程中发现了一个增加问题依赖性的可视化图表的建议。
GitLab中缺少Phabricator的哪些功能？请在评论中告诉我们，创建一个新的功能建议或在新的MR中开始你的贡献之旅。
封面图片由Johannes Plenio在Unsplash上拍摄。
