共计 2658 个字符，预计需要花费 7 分钟才能阅读完成。
前 言
Github 引入了 Pulll Request 拉取申请（简称 PR）实际和相干的反对性能，使运行开源我的项目的人更容易接受来自他们信赖的提交者群体之外的奉献。
Committer 是被信赖的主体，能够定期更改代码库。然而须要评估来自随机内部人员的更改，以确保其无效，不会使我的项目朝着不须要的方向倒退，并且合乎格调和质量标准。内部人员将他们提出的变更打包为拉取申请，Committer 能够轻松地将其作为一个单元进行审查和治理，而后再将其合并到代码库中。
（图 1：拉取申请流程）
只管拉取申请旨在更容易地承受来自团队内部不受信赖的人的奉献，但现状是很多团队对内部人员应用拉取申请。这种做法曾经变得如此广泛，以至于许多人将其视为默认的“最佳”实际。有些人认为没有其余办法能够确保代码失去评审，因为他们从未见过其余任何货色。
然而，拉取申请会就义性能，包含交付工夫和品质。当治理来自未知人员的变更危险时，这是一个值得做出的就义。内部人员可能不理解你我的项目的愿景和方向。他们在测试、代码品质和格调方面可能没有雷同的习惯和标准。然而，你本人团队成员外部应该共享这些标准。
针对本人团队成员的代码变更采纳拉取申请，就像让你的家人通过机场安全检查站进入你家一样，这是针对不同问题的低廉解决方案。
应用继续集成而不是拉取申请
软件交付过程应该针对流程和品质进行优化。将变更前置放弃在较短的工夫，并在变更引入问题时提供疾速反馈。这是反对继续集成 (CI) 的想法。CI 是在每个人的代码上一直合并和测试他们的做法。
（图 2：继续集成过程）
“当他们工作时”是必不可少的。作为团队成员，你不会等到实现某个性能或故事后才将代码集成到骨干中。相同，你常常 – 至多每天一次 – 将你的代码置于衰弱状态，通过测试并将其与其他人的当前工作一起集成到骨干中。（另请参阅 Martin Fowler 对于分支模式的文章和 Paul Hammant 的基于骨干的开发。）
每次推送变更时，CI 构建作业都会自动测试我的项目的骨干。这意味着在投入太多工夫之前，你会立刻发现你正在做的事件是否与另一个人正在做的事件发生冲突。当你认为曾经实现了一个故事或性能，却发现必须回去解决并重做这几天的致力，会很蹩脚。
（图 3：每次推送时都在集成代码上运行测试）
拉取申请的麻烦
拉取申请会提早集成。当实现工作，认为已筹备好与团队其余成员的工作进行集成时，你创立一个拉取申请并期待有人对其进行审核。只有在其他人审查通过变更后，才会将其与骨干集成。
如果团队成员疾速审查和集成拉取申请，这仅比 CI 慢一点。兴许他们会在你每次推送的 30 分钟内回复并审核，将你的代码变更与骨干集成，并针对它运行自动化测试。因而，你可能会在 30-40 分钟左右之后发现与其他人的工作发生冲突。
（图 4：拉取申请与 CI 的反馈提早）
在实践中，没有多少团队能在 30 分钟内牢靠地解决拉取申请。在期待某人审查你的变更时，你能够切换到另一个工作或开始解决新的批改。当发现存在问题时，你须要切换回原始更改，从而中断了以后的工作流程。
另一方面，无效的 CI 构建应该在推送集成代码后的几分钟内实现测试 – 在咱们的场景中最多 10 分钟。你简直会立刻发现该抵触，因而能够对其进行考察和修复。
在从测试齐全集成的代码中取得反馈之前，你无需打断其他人的工作来要求他们对其进行审查。正如我将很快解释的那样，你可能依然须要有人审核变更。然而你能够利用更快的周期时间来提交、集成和测试本人的代码，以便在要求他们审查之前进行多项更改。
即便团队中的每个人都很快地扭转了拉取申请，典型的做法是等到实现性能或故事的工作，而后再将拉取申请与骨干集成。大多数团队均匀须要超过一天的工夫来开发一个故事。因而，典型的拉取申请流程不满足继续集成的最低要求，即至多每天集成每个人的工作。
每天数次以编码、拉取、测试、推动和从集成测试中获取反馈的节奏工作会令人兴奋，而拉取申请在节奏中引入人为提早，不可能产生这种兴奋感。
审查代码更改更好的办法
当 CI 与拉取申请的话题呈现时，不可避免地会有人站进去为拉取申请辩护，以获取其余团队成员对更改的反馈。
必须有第二双眼睛（如果不是更多）查看代码更改。人类会发现测试没有发现的问题，尤其是与可维护性和设计相干的问题。让人们审查彼此的代码还有助于团队在编码格调、编程习惯和品质要求等标准上趋于统一。在某些状况下，例如受监管的环境，须要由第二人审查每个更改。
然而，最近拉取申请的风行仿佛导致一些人认为没有其余办法能够用来审查代码变更。以下是你能够应用的一些实际，而不会中断继续集成反馈周期。请记住，齐全能够依据须要进行多个实际的组合。
（图 5：配对以实现即时、继续的代码审查）
- 结对编程：没有任何模式的代码审查比结对编程更无效。反馈是即时的，因而应用它进行改良的可能性要高得多。如果有人在你编写代码时通知你有更好的办法，那么你能够立刻进行、学习并以更好的形式编写代码。如果有人在一天后通知你，你能够将其记录下来以备未来参考。然而要让你进行以后的工作并回去重做你曾经实现的工作，这会成为一个重大的问题。
- 定期审查：如果合规性没有明确要求进行审查，则可能不须要为每个代码更改设置一个门禁。你可能有定期的、预约的审查，例如每周，来查看自上次审查以来的代码更改。这作为小组练习尤其无效，因为它创立了对话，帮忙人们学习和塑造团队的编码标准。
- 流水线审批：如果你的团队应用继续交付流水线将变更交付到生产，能够包含一个阶段，要求有人受权变更进行。这在概念上相似于拉取申请，因为它是交付过程中的一个门禁，但当你将门禁放在代码集成和自动化测试之后。这样做意味着人们只花工夫审查曾经在技术上被证实是正确的代码。
（图 6：在集成和测试之后审查更改）
论断
拉取申请与继续集成的不同之处在于，在编写代码变更之后但在将其与主线集成之前，须要人工审查代码更改。这会提早从已齐全集成代码的自动化测试中获取到反馈。
应用继续集成，代码要么在编写时（配对）进行审查，要么在集成和测试之后进行审查。针对集成和测试变更的循环进行优化，意味着你能够更频繁地运行此循环。更频繁的编码和集成循环激励开发人员进行更小更频繁的提交，从而提高质量和流程。
作者：Kief Morris
译者：冬哥
原文：https://infrastructure-as-cod…
玩乐高，学麻利，规模化麻利联合作战沙盘之「乌托邦打算」，2022 年 3 月 5 - 6 日登陆深圳，将“多团队麻利协同”基因内化在研发流程中，为规模化晋升研发效力保驾护航！!🏰⛴公众号回复“乌托邦”可加入
