3

我正在通过颠覆学习整个版本控制，并为项目的所有不同工作/版本使用主干、分支、标签等。我也在尝试使用与 Jenkins 的持续集成来加快速度（尝试了 ccnet，设置真是一场噩梦！）。

所以我的问题是，如果我的项目 SVN 中有以下区域：

file:///E:/Data/SVN/MyProject/trunk
file:///E:/Data/SVN/MyProject/tags/version_1.0
file:///E:/Data/SVN/MyProject/branch/version_1.1

.. 在 Jenkins 中设置此构建项目的最佳实践是什么，以便持续监控我的 SVN 中的所有不同区域并构建任何更改？

我是否会设置一个项目，其中包含多个源代码存储库，每个版本/主干等一个？或者我会设置多个构建项目吗？我该怎么做？

编辑：我应该为此使用矩阵项目（构建多配置项目）吗？

4

2 回答 2

6

对于夜间构建（那些运行相对不频繁且需要较长时间的构建，通常是由于在其中完成了更多的自动化测试），矩阵项目非常适合。它的主要优点是“一点变化”——您不必编辑多个作业即可将相同的更改引入您的构建中。当然，这只适用于作业在分支之间几乎没有变化的情况（顺便说一下，这种变化通常可以由Run Condition Plugin巧妙地处理）。

在这种情况下，多配置项目可能不是最适合交付构建（交付构建在开发人员提交到存储库以检查他/她的更改是否集成良好时运行）。原因是，如果您致力于主干，您只想构建主干，但矩阵构建将构建所有内容（消耗计算资源和时间）。

对于交付构建，我将使用参数化构建，其中主要参数是要构建的分支。该构建可以由 SVN 挂钩触发（请参阅此文档）。或者，您可以为每个将轮询分支（通过Subversion 插件）的分支关联一个触发器构建，并通过Parameterized Trigger plugin使用适当的参数触发您的主构建。

顺便说一句，我实际上使用了所有上述方法（除了 SVN 钩子，我不再这样做，不完全是技术原因）。

于 2012-06-05T19:42:08.380 回答
3

设置多个作业，一个用于您要构建的每个分支/标签。一旦你得到一个工作正常，你可以复制它来创建其余的，只更改 SVN URL。

当您停止维护这些标签/分支时，您还应该摆脱旧工作，以免您的 Jenkins 配置失控。

于 2012-06-05T19:32:59.977 回答