关注留言点赞，带你了解最流行的软件开发知识与最新科技行业趋势。
希望简化您的 GitHub 管道但不确定从哪里开始？了解何时使用 gitStream、代码所有者和 GitHub Actions。
代码审查是所有软件开发项目的重要组成部分。但有时，您的组织遵循低效的 PR 流程，将相同的策略集应用于每个拉取或合并请求，无论更改如何。这可以增加从进行更改到将其发布到生产的准备时间。您团队的周期时间也会受到巨大打击，您的开发人员会感到沮丧。
但是新方法不断涌现，使 PR 生命周期更加顺畅。这些通常混合自动化和人工交互以减少合并时间。在本文中，您将了解一些有助于自动化工作流程的新工具，包括 GitHub Actions、代码所有者和 LinearB 自己的 gitStream。
什么是 GitHub 操作？
GitHub Actions是一个 CI/CD 平台，允许您创建管道以自动执行构建过程。操作就像您在存储库中编程和执行任务时将使用的方法。GitHub Actions 可以支持合并过程，但需要您自己进行大量设置。如果找不到执行所需活动的预先存在的操作，则需要从头开始创建它或查找开源示例。
虽然此工具的自动化方面可以等同于更高的效率，但默认情况下，Actions 在存储库级别工作，并且在 YAML 中没有大量高度具体的工作的情况下不提供大量精细控制。这意味着设置和维护可能需要花费大量时间。自动化过程还可以允许在未经合并请求批准的情况下自动合并低质量代码。GitHub Actions 仅限于 GitHub，并不像 Code Owners 那样多才多艺 — 接下来您会发现原因。
什么是代码所有者？
代码所有者是 Git 等版本控制系统中的一项功能，它允许用户将所有权分配给特定的文件或目录。它确保指定的所有者在将更改合并到代码库之前审查更改。您还可以使用代码所有者来自动化工作流程，例如在进行更改时触发通知所有者。它通常用于开源项目以管理来自外部贡献者的贡献。
代码所有者功能于 2017 年由 GitHub 首次引入。虽然 GitHub 并未发明代码所有者的概念，但它通过将代码所有者集成到其平台并让开发人员更广泛地访问它来普及它。从那时起，代码所有者的采用就非常普遍，特别是在使用基于 Git 的版本控制系统（如 GitHub、GitLab 和 Bitbucket）的开发人员中。这些平台都以某种形式支持代码所有者，允许用户分配代码所有权和自动化工作流程。
GitHub 代码所有者
在 GitHub 中，代码所有者使您能够使用名为 CODEOWNERS 的文件配置存储库的代码所有者。这有助于您确保合适的人正在审查他们最感兴趣的代码。
您可以将存储库配置为仅允许在默认所有者批准后合并代码。您甚至可以将其进一步分解，以便特定文件需要代码所有者批准，而任何人都可以批准其他文件。
使用 GitHub CODEOWNERS 文件可以降低未经代码所有者批准而合并更改的风险，这有助于提高整体代码质量。但这会降低效率，尤其是当这些特定的开发人员需要审查许多更改时。
例如，当 Symphony Talent 使用代码所有者时，他们最终陷入了八个高级开发人员必须 审查所有PR 的情况。他们每个人每天都会收到几十个 PR，没有所有权就没有办法管理这一切。不知道谁应该审查什么，这造成了瓶颈。有了 gitStream，他们现在可以根据 PR 作者团队分配审阅者，每个团队都有一个高级审阅者。
GitLab 代码所有者
与 GitHub 类似，使用GitLab code owners，您可以定义谁开发和维护功能并拥有存储库中的结果文件或目录。使用 CODEOWNERS 文件，您可以确保合并请求在合并之前得到代码所有者的批准，甚至可以通过仅允许代码所有者批准对分支的更改来保护特定分支。
您还可以使用 GitLab Code Owners 和approvers（具有批准规则）来构建更灵活的工作流程。这要求您：
- 使用代码所有者来定义对存储库中的特定路径具有领域专业知识的用户
- 使用批准者和批准规则来定义不限于存储库中特定文件路径的专业领域（例如安全团队）
观看这段关于 GitLab 代码所有者的视频，了解更多信息：
CODEOWNERS 文件示例
在根目录中创建一个名为 CODEOWNERS 的新文件，在您要添加代码所有者的分支中。
YAML1个# 这是一条评论。2个# 每行是一个文件模式，后跟一个或多个所有者。3个的4个的5个# 这些所有者将是所有内容的默认所有者6个# 回购。除非以后的比赛优先7# @global-owner1 和@global-owner2 将被请求8个# 当有人打开拉取请求时进行审查。9的10* @global-owner1 @global-owner211的12的13# 顺序很重要；最后一个匹配模式占用最多14# 优先级。当有人打开拉取请求时，只有15# 修改 JS 文件，只修改 @js-owner 而不是全局的16# 所有者将被要求进行审查。17的18*.js @js-owner #这是一个内联注释。19的20的21# 在此示例中，@doctocat 拥有构建/日志中的任何文件22# 存储库的根目录及其任何23# 子目录。24的25/构建/日志/@doctocat26的27的28# `docs/*` 模式将匹配像这样的文件29# `docs/getting-started.md` 但不是进一步的嵌套文件，例如30#`docs/build-app/troubleshooting.md`。31的32文档/* docs@example.com33的34的35# 在此示例中，@octocat 拥有应用程序目录中的任何文件36# 存储库中的任何位置。37的38应用程序/ @octocat
什么是 gitStream？
gitStream是一个动态规则引擎，允许您定义 PR 条件和结果。您可以用它实现代码所有者的相同行为。不同之处在于，您可以添加更多条件，而不仅仅是基于文件路径模式，并且可以使用动态数据。
例如，您可以根据撰写 PR 的人和其他条件（如文件路径）分配审阅者。您还可以根据代码源代码控制历史的动态分析来分配审阅者，例如“rankByGitBlame”等。
例如，eMed 在包含二进制资产和 JSON 文件的存储库上使用 gitStream 来支持他们的程序脚本。其中一些程序已投入生产，但许多是严格的内部测试数据或客户无法获得的开发中资产。
他们想要一个系统，可以让不同的人（临床、法律、用户体验和设计等）正确审查实时生产资产和程序，但可以自由部署开发和测试资源。
如果更改严格按照格式进行，而没有任何实质性内容，他们甚至希望自动批准生产程序。他们从来没有完全能够使用代码所有者来实现这种复杂性，但是使用 gitStream 它工作得很好！
想了解如何实施自定义开发工作流自动化以将代码审查时间缩短多达 40%？观看此实践研讨会以设置免费的 gitStream 工具以自动执行以下操作：
- 分类和路由拉取请求
- 为 PR 添加预估审核时间
- 应用自定义规则
gitStream 产品负责人 Ofer Afias 将在开始使用 gitStream 工作流自动化时带您完成三个核心功能的现场演示，以有效地扩展您的团队并改善您的开发人员体验。
gitStream vs. Code Owners vs. Git Actions
在为您的团队选择工作流自动化工具时，需要考虑的四个最重要的因素是工具的 1) 可扩展性、2) 风险、3) 效率和 4) 定制。这些因素会影响该工具处理不断增加的工作负载、最大限度地减少潜在问题、优化性能和满足独特开发需求的能力。
如果这四个因素不一致，您的团队就无法成功。因此，我们针对这些关键因素分析了每个工具来帮助您！
1.可扩展性
使用 Git 代码所有者是可扩展性最低的方法，因为开发人员仍然需要在合并代码之前执行手动代码审查。如果同一个人必须审查大量拉取请求，那么在代码所有者努力追赶的过程中，流程可能会成为一个巨大的瓶颈。
gitStream 和 GitHub Actions 的可扩展性要高得多。它们都使合并过程自动化，并且可以防止对琐碎的更改进行不必要的人工审查。gitStream 甚至可以根据在添加新团队成员时不需要编辑的几个标准自动执行审阅者选择过程！
2. 风险
GitHub Actions 具有可扩展性但存在风险，因为它们甚至允许合并质量较差的代码更改。相比之下，Git 代码所有者不允许代码在没有特定人员批准的情况下通过合并请求，因此风险较低。但这是以难以扩展为代价的。
在风险方面，gitStream 优于其他两种方法。它提供了一个更复杂的规则集来确定哪些更改可以自动批准，哪些需要代码所有者的批准，哪些需要多个审阅者。
3.效率
如果您正在寻求效率，那么使用 Git 代码所有者并不是一个好的选择。代码所有者可能会因为对活动代码库进行耗时的审查而陷入困境。GitHub Actions 高效且具有自动化功能，但它们的高风险性质意味着您的团队将不得不处理越来越多的错误，从而降低他们的整体效率。
GitHub Action 也是一种低级操作，需要努力编码、测试和维护。另一方面，gitStream 是一个更高级别的系统，它允许您非常轻松地应用许多自动化规则。同样，gitStream 提供了优于其他方法的显着优势。它确保您的团队不会在低级别审查上浪费时间，同时还消除了错误风险。
4.定制
所有这三个选项都提供了一定程度的自定义，例如定义代码所有者是谁以及指定哪些更改可以自动合并。但是代码所有者只允许您选择审阅者是谁以及哪些文件很重要。虽然您可以在某种程度上自定义 GitHub Actions，但它们仅限于特定范围。
gitStream 提供了最多的选项，有效地提供了 GitHub Actions 和代码所有者的功能——然后是一些。gitStream 建立在 GitHub Actions 之上，并与它们有一些相似之处。但是 gitStream 为您提供了更多的功能和粒度，直到与正则表达式匹配的文件级别，而不是影响整个存储库。gitStream 也是免费的，并且可以比 GitHub Actions 更快、更动态地实施。
奖金回合
gitStream 可以实现与使用 GitHub Code Owners 相同的功能，同时还使您能够合并其他条件以更好地满足团队不断变化的需求。
该工具还提供了更广泛的用例。例如，它使您能够自动化更复杂的 Git 工作流程，例如自动标记拉取请求、触发对外部工具或系统的通知，以及根据多个条件路由拉取请求。这允许您的团队优化他们的 Git 工作流程，以更好地符合他们特定的开发流程和要求。
为了帮助您更快地做出决定，请查看下表以快速回顾每个工具的排名：
方法可扩展性风险效率客制化GitHub 操作缓和高的高效的一些定制代码所有者低的低的效率不高有限定制git流高的低的非常有效率高度定制化
何时使用每种工具
每个工作流自动化工具都有其优点和缺点，但它们都可以在特定环境中发挥作用。为了帮助您解决问题，我们重点介绍了三种情况，您可以根据您团队项目的规模和范围选择这三种工具中的任何一种。
复仇者联盟和八爪猫，集结！他们能帮助您找到所有问题的 (g) 根源吗？
1. 使用 GitHub Actions 的低复杂度项目
GitHub Actions 非常适合快速移动、低复杂度的项目。因为 GitHub Actions 允许快速合并，所以提高的速度可能会超过风险。当质量不是您的主要关注点时，GitHub Actions 可以帮助您加快项目速度。所以当你有一个小团队在一个相当简单的项目上工作时，它会很有效。
也就是说，GitHub Actions 不适合具有更关键、更复杂元素的大型项目。虽然 GitHub Actions 可以帮助您更快地完成项目，但当出现错误时它们并不理想。该工具提供的初始速度提升肯定会导致代码破坏错误，从而阻止您的进步。
2. 较小代码库的代码所有者
代码所有者提供了一种低风险、低速度的代码合并方法。这使得代码所有者成为没有紧迫期限的小型项目的有用方法。CODEOWNERS 文件也适用于没有受到高度监管和审核的应用程序的项目，在这些项目中，即使是最小的错误也可能带来灾难性的后果。
代码所有者也不适合频繁更改的大型代码库，因为代码所有者很快就会被审查淹没。代码所有者可以帮助确保团队代码的质量，但这是有代价的——速度。
3. 使用 gitStream 简化多代码库企业应用程序
gitStream 针对具有任意数量开发人员的任意规模的项目进行了优化。它根据更改的上下文提供自动合并和人工代码审查的最佳组合。这使得 gitStream 适用于大多数真实世界的用例，特别是如果您有一个拥有多个存储库的大型工程团队，每个存储库都有不同的所有者和专家。
gitStream 确保代码快速合并，同时保持质量，因此您可以安全地缩短周期时间。作为奖励，gitStream 可以帮助您消除开发团队经常面临的最大瓶颈：缓慢的 PR 周期。所以 gitStream 不仅可以在保持质量的同时加快您的流程。它还可以提高开发人员的士气并减少他们的挫败感。
进行合并
使用策略即代码标准化您的 PR 审查流程很重要，因为合并所需的时间可能会导致错误修复、功能发布和团队的整体周期时间延迟。避免引起开发人员的焦虑也很重要，因为他们无法在所有不断的上下文切换下做任何工作。
如果您希望提高合并频率，GitHub Actions 和代码所有者可能是不错的选择。但是您需要注意项目的规模和风险偏好，以避免为了速度而牺牲质量，反之亦然。
另一方面，gitStream 可帮助您的团队创建动态代码所有者规则，以便您可以在保持高质量代码的同时不断合并。该工具标志着对所有拉取请求的一刀切程序的转变，这种程序会减慢您的合并时间并对周期时间产生负面影响。
gitStream 还允许您的团队超越这些严格的要求，调整所需审查的深度并根据最合适的人选分配审查人员。因为 gitStream 可以无缝处理不同规模的项目，而且是免费的，所以它是大多数现实世界商业项目的绝佳选择。
热门跟贴