检查持续集成答案

【问题标题】：Check Out for Continuous Integration检查持续集成
【发布时间】：2009-10-21 02:02:14
【问题描述】：

从版本控制软件中检查代码以执行持续集成或夜间构建时，你们通常会做什么？您是 1) 拉取最新代码，还是 2) 通过代表开发人员要测试的最新代码的某个标签（即 FUNCTIONAL）拉取？

我想这个问题的答案取决于人们通常如何使用他们的配置管理存储库。您是否打算仅存储“完整”的代码。如果是这种情况，如果开发人员在某项任务上工作了一周左右，他/她将无法签入任何内容，直到任务完全完成。然而，如果持续集成服务器只是简单地通过一个众所周知的标签来拉取而不是拉取最新的代码，那么这将允许开发人员非常频繁地签入代码，因为他们正在努力存储他们正在进行的工作的历史记录。然后，一旦他们对更改感到满意，他们就可以用 FUNCTIONAL 标记标记他们的新代码。

只是想了解最佳做法。

谢谢

【问题讨论】：

您假设开发人员无法在不造成损坏的情况下完成任务，但这不一定是正确的，特别是如果他们在每次提交之前运行一套单元测试，并避免测试失败时提交。

标签： version-control continuous-integration

【解决方案1】：

所以我们通常做的是有一个 CI 服务器构建的“构建”分支。我们将希望包含在夜间构建中的所有内容合并到构建分支中，它会在那里构建。

我们实际上并没有针对构建分支进行开发，我们有开发分支用于保存尚未准备好发布到测试环境的更改。

【讨论】：

你用什么工具？它是否使连续分支和合并变得非常简单？
我们使用 TeamCity。 CI 服务器实际上并没有做任何分支和合并，这仍然取决于开发人员来做。 CI 服务器所做的是检测对特定 SVN 分支的提交并触发构建。构建包括编译应用程序、运行单元测试并将应用程序部署到服务器

【解决方案2】：

我为 CI 提出的主要建议（更像是经验法则）：

让它从校长。让你的头/主人总是尽可能最新尽可能稳定。
没有人可以将损坏的代码提交到校长。如果发生这种情况，它表示有人破坏了构建。
破坏构建的人必须是承诺尽快修复可能。
让您的 CI 在一个每个提交的基础。所以，只要有人向 HEAD，CI 将得到它并打破构建。大多数 CI 的服务器我见过支持这种方式的作案手法。
您还可以让您的 CI 生成夜间构建并标记当他们生成代码时包。这也是一个好练习，你可以看到来自开源的许多 CI 世界各地的项目。

我的一些经验：我们的 CI 可以从 HEAD/MASTER 中提取代码。我们在这里使用 git，因此我们的开发人员总是很容易在分支上工作并保持同步 - 但他们只能将稳定的代码提交到 HEAD/MASTER。

【讨论】：

我同意上面的大部分观点 - 一个谨慎的想法 - 我发现如果一个在每个提交的基础上运行的 CI一个大型项目的模块同时进行。提交的频率往往会使 CI 服务器不堪重负，尤其是在您进行大量测试的情况下。在这种情况下，尝试批量构建以在一定数量的提交后或按计划运行。

【解决方案3】：

正确的答案取决于您如何组织代码。

如果主线总是应该是稳定的/工作的，那么你只需从中构建。

如果你有一个分支是“黄金”分支，那么......

在我们的店里，我们有三种分店：

主线 // 始终可构建，始终“一旦完成 QA 即可发布”
已发布的分支 // 黄金，可随时发布和发布
开发分支//完成凌乱的手术

（当然要做好这件事需要一个好的 vcs。我们使用 perforce，它有很棒的分支。）

我们从主线和发布分支进行持续构建。

HTH

【讨论】：