我知道这已经被问过了，但我们真的很想拒绝任何提交文件的尝试，这会破坏主干中的项目。拒绝提交文件的决定是基于提交文件所属项目的构建过程的结果。我知道在预提交阶段无法同时访问存储库，但这对我们来说不是问题，因为我们的构建速度非常快，我们可以容忍任何延迟。
有什么工具可以实现我们想要的吗？请注意，有必要重新编译整个项目单元，而不仅仅是提交的单个文件。
如果这不能以任何合理的方式完成，是否可以在提交后构建代码，然后在构建步骤失败的情况下立即回滚？Hudson 或其他工具可以配置为我们想要的吗？
问问题
5063 次
3 回答
9
即使您的构建速度很快。假设您可以在 90 秒内构建整个项目。您是否希望人们每次提交代码时都等待 90 秒？可能发生的情况是人们只会做更少的提交，做出更大的改变，并导致更多的错误。
首先要意识到，进行糟糕的修订并不是世界末日。如果您及早发现问题，您可以轻松地恢复更改。这里的关键是早期发现。
如果您还没有，请获得像Jenkins这样的持续集成系统。每当有人提交代码更改时，Jenkins 都会进行构建。如果构建的速度与您声称的一样快，那么您将在几分钟内收到更改中断构建的通知。如果您愿意，您甚至可以让 Jenkins 恢复更改。我们的理念是开发人员有 10 分钟的时间来解决问题，或者恢复他们的更改。然后，我们把它们放在栅栏里，用腐烂的西红柿剥皮。（实际上，HR 不会让我们这样做。）
其次，设置易于遵循的标准，允许开发人员确保他们的更改将起作用。我们有一些基本的：
- 我们定义了一组所有开发人员都应该拥有的基本工具（Java、Ant、Subversion）。
- 除了这三个基本工具之外，所有其他工具和所需的部分都放在工作目录中并签入 Subversion。
- 不需要特殊的环境设置。构建不需要配置等。
- 构建完成后，所有构建的对象都在工作目录中完成。
这使我可以轻松地在我们的 Jenkins 服务器上设置构建。而且，更重要的是，它使开发人员可以轻松地使用 Jenkins 将用于构建的相同构建系统。如果他们可以构建它，Jenkins 就可以构建它。
接下来，你必须改变你的开发文化。破坏构建是不好的。一旦完成，Jenkins 将公开羞辱任何破坏构建的开发人员。我看到的一家商店设置了红绿灯。如果 Jenkins 构建失败，那些灯就会变成红色。发生这种情况时，这是一件大事。经理们出来了，想知道发生了什么事。当我在那里时，那些灯从未变红。
当然，能够运行构建是软件的第一步。这是一个小小的婴儿步骤 - 甚至可能是爬行。不，甚至不是，这是一个六个月大的婴儿第一次爬行的版本。如果损坏的构建是您所在位置的主要问题，那么您将遇到非常严重的问题。
除了确保一切都编译之外，下一步是确保代码遵循编码标准并且代码没有做一些可能不好的事情。在 Java 世界中，它针对代码运行 Checkstyle、Findbugs 和 PMD。Jenkins 允许我发布漂亮的图表，向我展示这些程序的结果。我们还收集所有编译警告和 JavaDoc 错误并绘制它们。如果这些进程中的任何一个发出太多警告，我们甚至可以设置 Jenkins 以使构建失败。您的代码可能会编译，但由于技术不佳，构建会失败。
接下来是单元测试。在 Java 世界中，它是 JUnit，Jenkins 再次显示结果。如果任何 JUnit 测试失败，我们就会失败构建。如果您的基本界面很糟糕，那么构建良好的构建并没有多大好处。
然后是代码覆盖率。我们有多少代码在进行单元测试。我们为此使用 JaCoCo。我们不会因代码覆盖率低而导致构建失败，但我们会向开发人员施加压力以提高代码覆盖率。最后，我们可以进行其他测试。我们部署并运行自动化功能和系统测试。
开发人员所做的每一次更改都会被一路轰炸到单元测试。这是我真正喜欢 Java 的地方之一，我认为 Java 开发在这方面遥遥领先。典型的 Java 构建可以在几分钟内完成。我们无法在 10 分钟内构建并运行所有单元测试的情况很少见。任何问题都会尽早发现并尽早解决。而且，所有问题都在 Jenkins 中公开展示。我们看到是谁破坏了构建或导致单元测试失败。我们看到谁有需要修复的编译器警告，或者做了一些糟糕的编码练习。
而且因为我为开发人员提供了 Jenkins 用于构建的相同工具集，所以他们可以很容易地看到 Jenkins 会看到什么。他们也可以运行单元测试和代码测试。他们没有理由提交导致比解决的问题更多的代码。
这就是您取得长足进步的地方：改善开发文化以关心他们在做什么，并对不良做法发出明亮的光芒。
在开发前设置障碍——比如让开发人员在每次提交后等待 90 秒以确保他们的更改得到构建——会产生怨恨并且通常会适得其反。您不再是团队的一员，而是将每个人都视为潜在嫌疑人的建筑警察。相反，与开发人员合作并说服他们你想要的对他们有利。一旦他们看到这一点，他们就会与您合作，您的整个开发周期就会运行得更加顺畅。
于 2013-05-24T13:26:45.563 回答
0
我知道一些 CI 工具能够执行“预提交 CI”，因此首先将变更集发送到 CI 服务器进行构建，一旦可以成功构建，然后将其提交给 SVN。
我没有亲自尝试过这样的功能，但我相信工作流程可能需要稍微改变（而不是直接提交，更改被发送到 CI 进行预提交构建）
于 2013-05-24T09:28:49.677 回答
0
在大多数情况下，您提交到一个分支，它会被构建，如果成功，分支代码会合并到一个主干。这更适合大多数没有明确支持您所要求的 SCM 系统 - 考虑到 scm 将仅发送更改的文件，并且您需要检查构建服务器的完整列表才能工作（您并不真的想要根据以前构建中留下的文件进行编译，你现在做）。
SVN 可以在 pre-commit 挂钩中愉快地执行此操作，我在此挂钩中使用 perl 脚本来检查可接受的签入注释并拒绝可能添加到存储库中的不可靠文件类型，因此没有理由不能简单地运行脚本签出当前分支，然后将提交文件复制到它们的顶部，构建，然后检查构建日志。要使预提交失败，只需从脚本中返回 1（返回 0 以通过它）。
很难准确地说出您需要什么，因为我不知道您正在执行构建什么或如何执行构建，但是您的脚本需要与任何预提交挂钩脚本几乎相同。SVN 附带了几个示例，您可以在 Internet 上看到更多示例。
于 2013-05-24T11:38:12.800 回答