进行持续集成时应何时进行代码审查？

我们正在尝试切换到持续集成环境，但是不确定何时进行代码审查。根据我对持续集成的了解，我们应该每天尝试多次检入代码。我认为，这甚至意味着尚未完成的功能。

所以问题是，我们什么时候进行代码审查？

在签入代码之前，我们无法执行此操作，因为这会减慢我们无法进行每日签入的过程，更不用说每天进行多次签入了。

同样，如果我们正在检入的代码只是编译但功能不完整，那么进行代码检查就没有意义，因为大多数代码检查最好在功能完成时完成。这是否意味着我们应该在功能完成时进行代码审查，但是未审查的代码将进入存储库？

IMO，您应该在将代码发布到主线之前对其进行检查，以使主线只有最高质量的代码。

OTOH的好处是，“为什么要检查CI测试自动化系统是否还没有运行？”，所以最好的办法是为开发人员提供一个私有分支，CI服务器将为其构建并对其进行测试。 。这样，他们首先提交并推送到那里，然后通过审查，然后合并到主线（在那里它将通过CI服务器再次运行）。

您绝对应该查看未完成功能的代码，以确保为将来的功能建立了脚手架，或者至少没有放置任何东西来阻止实现所述将来的功能。

另外，请注意，代码审查不一定要缓慢或同步-像gerrit或reviewboard之类的工具可以使它们异步且相当轻松。

（完整披露：我曾经为代码审查工具Code Collaborator的制造商SmartBear工作）

设置结对编程？

在键入所有代码时都会对其进行检查，而无需扩展流程或引入其他步骤。

这是连续交付作者的摘录：

杰兹·汉布尔（Jez Humble）写道：

我目前正在撰写有关该主题的博客文章。简短的答案是这样的：

• 查看代码的最佳方法是通过配对编程
• 将合并合并到主线是一个坏主意-例如，通过在正式的审核过程中创建一个单独的分支。这抑制了持续集成（减少真正更改的最佳方法，这是降低不良更改风险的最佳方法）。
• 我认为Gerrit是个不错的工具，但是应该在签入后使用（实际上就是这样设计的）。高级开发人员的部分工作是对所有签入进行复查。例如，他们可以订阅供稿。

总结一下：代码审查很好。太好了，我们应该通过配对编程和审查提交来连续地做到这一点。如果高级开发人员发现错误的提交，则应与提交错误的人员配对，以帮助他们解决问题。

出于正式考虑，将门合并到主线上进行正式检查是不好的，而创建分支来这样做是特别糟糕的。

谢谢，

哎呀

原始链接是：https : //groups.google.com/forum/#!msg/continuousdelivery/LIJ1nva9Oas/y3sAaMtibGAJ

我不知道这是否是最好的方法...但是我会解释我们如何做。一个或多个开发人员在给定的分支上工作，并尽可能多地提交代码，以避免浪费时间，否则这些合并就不会发生。仅在代码准备就绪时，才将其提交到头部。现在，这是关于提交和分支/头的事情。

至于代码审查，我们使用Sonar作为我们的持续集成工具（和Maven / Jenkins用于与Sonar进行交互），以便每天早晨为我们提供新鲜的测试结果，代码覆盖率和自动代码审查（每晚进行构建），以便我们开发人员每天早晨最多可以花费一小时来解决他们的问题/代码异味。每个开发人员都要为自己编写的功能负责（也要为此感到自豪！）。现在，这就是自动代码审查，这对于发现潜在的技术/体系结构问题非常有用，但是更重要的是测试这些新实现的功能是否正确执行了企业希望他们做的事情。

为此，有两件事：集成测试和对等代码审查。集成测试有助于合理确定新代码不会破坏现有代码。至于对等代码审查，我们将在星期五下午进行，这是一个比较轻松的时间：-)每个开发人员都被分配到一个他不工作的分支，这需要一些时间来阅读其要求。新功能，然后检查已完成的操作。他最重要的工作是确保新代码在给定要求的情况下能够按预期工作，不会破坏我们自己的“规则”（为此使用该对象，而不是该对象），易于阅读，并且允许易于扩展。

因此，我们有两种代码审查，一种是自动审查，一种是“人工”审查，我们试图避免将未经审查的代码提交到HEAD分支中。现在...有时候确实会由于各种原因发生，但我们远非完美，但我们试图在质量和成本（时间！）之间保持合理的平衡。

@pjz也提供了一个很好的答案，他提到了代码审查工具。我从未使用过任何东西，因此我对此一无所获...尽管由于我们已经在使用JIRA，过去我很想与Crucible合作。

我认为将有用的主要概念是“暂存”区域的概念。

是的，您不想检入已损坏的代码。但是您也应该经常检查代码。这是否意味着完美？;）不。只需使用多个区域和git等DVCS。
这样，您可以（本地）进行更改，并在测试和开发过程中经常提交更改，直到测试通过。然后，您进入暂存区域进行代码检查。

然后，您应该从“暂存”过渡到其他质量检查工作，例如浏览器测试和用户测试。最后，您可以去批量测试区域，然后是最终生产。

其中也包括工作流，例如每个人都在主分支上工作或使用单个分支进行所有工作。

持续集成本身也可以在多个级别上进行。它可以是开发人员机器本地的，直到“测试通过”，也可以是阶段和质量检查区域中的代码何时到达测试区域。

解耦代码审查和持续集成！

为什么将它们组合在一起？

我们将git flow用于我们的存储库，并在合并到developer分支时进行代码审查。

开发中的所有内容都是完整的，可部署的，并且代码已审查。

我们还为开发和主分支机构设置了CI。

我真的真的认为您需要DVCS（例如，mercurial，git）自然地做到这一点。有了CVCS，您将需要一个分支机构，并希望对您拥有的任何上帝都没有合并的地狱。

如果使用DVCS，则可以对集成过程进行分层，以便代码在到达CI服务器之前已经对其进行了检查。如果您没有DVCS，那么代码将在检查之前到达CI服务器，除非代码检查人员在每个开发人员的机器上提交更改之前检查代码。

第一种方法，特别是如果您没有可帮助发布个人存储库（例如bitbucket，github，rhodecode）的存储库管理软件，则是具有层次集成角色。在以下图表中，您可以让中尉来审查开发人员的工作，并让独裁者作为主要集成者来审查中尉如何合并工作。

如果您拥有存储库管理软件，则另一种方法是使用如下工作流程：

存储库管理软件通常在存储库中有活动（例如电子邮件，rss）以及允许拉取请求时帮助发出通知。在上拉请求期间，代码审查会自然发生，因为上拉请求通常会使人们参与对话以集成代码。以该公共请求请求为例。该整合经理实际上不允许，如果要修正的代码需要代码到达的祝福库（又名“中央资源库”）。

最重要的是，有了DVCS，您仍然可以支持集中式工作流程，如果您不想，则不需要其他花哨的工作流程...但是，有了DVCS，您可以将中央开发存储库与CI分开服务器，并授权某人在完成代码审查会话后将更改从开发库推送到CI库。

PS：图片的版权归git-scm.com

为什么不拥有多个存储库？一个用于“日常”工作，驱动一个连续的集成服务器，运行所有的单元测试和集成测试以获得良好的紧密反馈环，另一个用于“稳定”的工作，提交频率较低，但是必须进行审查。

根据更改在系统中移动的路径而定，这最终可能会成为一个复杂的解决方案，并且在使用诸如Git或Mercurial Queues之类的工具时可能效果最佳（注意：我从未在愤怒中使用过）但是许多组织都做类似的事情。

这是否意味着我们应该在功能完成时进行代码审查，但是未审查的代码将进入存储库？

以上是我在至少三个项目中使用连续集成进行密集工作的方式，并且据我回忆，它的工作原理很有吸引力。这种做法被称为提交后代码审查 -如果您对详细信息感兴趣，请在此词搜索网络。

• ^{另一方面，当我一直在项目中试图与CI结合“ 预先提交”代码审查的唯一情况时，结果却很痛苦。好吧，当一切顺利进行到100％时，就可以了-但是即使是很少的中断（例如，当主审和备用审阅者都无法使用几个小时时）也会造成明显的压力。我还注意到，团队士气有些受挫-冲突太多了。}

首先，我们应该澄清“持续整合”的概念。在传统的开发方法中，持续集成意味着我们每天都可以集成和构建我们的源代码存储库，这将避免“集成地狱”的陷阱。代码检查始终在编码和单元测试之间。我们必须保证合并到分支的代码可以正确编译。由于很难处理接口的一致性和编译错误，因此很少有功能的某些部分合并到分支的情况。

持续集成在极限编程过程中很流行。测试驱动的开发增加了结对编程，结对编程是代码检查过程的实际组成部分，使连续集成易于实现。极限编程本身是一个连续的代码审查和集成过程。代码审查无处不在。

在一些开源社区中，代码审查是在代码合并到分支之前执行的。这个团队中总是最有经验的人来进行代码审查并决定代码是否可以合并到主分支。这样，持续集成的时间会更长一些，但是代码质量会更好一些。

返回问题。何时进行代码审查没有标准答案，这取决于您的原始开发过程和持续集成的实际实现。