svn - 与 Subversion 和 CVS 的持续集成

Question

在我目前从事的项目中，我们同时使用 Subversion 和 CVS。开发人员通常会开发代码并 checkin CVS/Subversion。

当编码完成并且所有内容都已 checkin 时，我们使用测试标签标记存储库，并使用使用 TEST 标签 checkout 的代码进行正式测试。

我们不使用 trunc 标记，而是使用以前的标记:

- Tag RELEASE.0.1 as PROJ-ABC-LIVE.1.3
- Tag revision 12 as PROJ-ABC-LIVE.1.3 (new changes not part of RELEASE.0.1)

以上确保只有来自上一个版本的文件 + 新修订版被标记为新版本标签，从而排除任何未经测试的内容。

当测试完成并对代码进行任何其他更改(作为测试的结果)时，代码将被标记为 LIVE 标签。 LIVE 标签是 checkout 并部署到 LIVE 服务器上的代码。

在任何时候，存储库的截断都可以包含人们所做的任意数量的更改。在某些情况下，人们会 checkin “进行中”且不完整的代码更改。有人签到东西然后去度假两周是完全正常的。

这里的示例是我们存储库中修订文件的示例状态

1.4
1.5
1.6 PROJ-ABC-TEST.0.1
1.7 
1.8 PROJ-ABC-TEST.0.2
1.9 PROJ-ABC-LIVE.1.3
1.10
1.11

当我们发布版本时，我们会检查带有 PROJ-ABC-LIVE.1.3 标签的所有内容，并将其作为正式版本发布。不包括修订版 1.10 和 1.11，因为这些是当前 trunc 中的新更改。

我很难理解在这种情况下如何使用 Jenkins 或 Hudson 之类的东西。如果我们引入它，它到底能为我们做什么。

如果我们引入它，它不会每次都构建相同的版本吗？我们只使用标签构建，所以如果我引入 Jenkins/Hudson，我将不得不将它配置为通过标签构建。它不会每次运行时都构建 PROJ-ABC-LIVE.1.3 吗？除非可以使用最新标签进行构建。

我见过的关于如何使用 CI 的大多数示例是大多数人每次在存储库中发生更改(提交)时都从 trunc 构建。如果人们 checkin 不完整的工件，这将如何工作？如果 trunc 永远不稳定(这不是故意的)，我真的看不出从 TRUNC 构建的好处是什么。

也许我对 CM 不是很了解，但是如何发布从 Trunc 构建的东西？我想我的问题是

• 在截断包含不完整工件的情况下如何使用 CI
• 如果所有交付都使用标签，CI 环境是否会在每次运行时重新构建相同的代码？标记的快照永远不会改变——因此 CI 环境没有用吗？
• 如果我们不从 trunc 构建，CI 是否有用？从 Trunc 构建到底有什么好处？
• 如果它能够检测是否应用了新的 LIVE 标签并从中构建，我认为它可能对我们有用的唯一方法。这可能吗？
• 是否还有其他我错过的可能对我们有益的场景？

谢谢

Answer 1

简短的回答(正如@JB 强烈暗示的那样)是您根本没有使用 CI 进程——因此 CI 服务器对您帮助不大。我强烈建议您的团队切换到 CI 流程。这是一个seminal paper by Martin Fowler关于它的全部内容。祝你好运!