构建管理/持续集成最佳实践答案

【问题标题】：Build management/ Continuous Integration best practices构建管理/持续集成最佳实践
【发布时间】：2010-09-29 23:17:11
【问题描述】：

您的团队如何处理构建？
我们使用 Cruise Control，但是（由于缺乏知识）我们面临一些问题 - Code freeze in SVN - Build management
具体来说，当代码不断被检入时，如何提供特定版本？

一般来说，您能谈谈您在发布管理中使用了哪些最佳实践吗？

【问题讨论】：

标签： java build-process release

【解决方案1】：

看看continuous integration: best pratices，来自 Martin Fowler。

嗯，我已经找到了一个related thread，我在一年前参与了。您可能会发现它也很有用。我们就是这样做的。

[已编辑]

我们使用 Cruise Control 作为集成工具。我们只处理主干，在我们的例子中它是主要的 Subversion 存储库。当有可能发生复杂的冲突时，我们很少会抽出新的分支来制作新的故事卡。通常，我们为版本发布拉出一个分支，并从中创建构建并将其交付给我们的测试团队。同时我们在trunk中继续工作，等待测试团队的反馈。一旦所有测试完成，我们就从分支创建一个标签，在我们的例子中它在逻辑上是不可变的。因此，我们可以随时向任何客户发布任何版本以防万一。如果版本中出现错误，我们不会创建标签，我们会修复分支中的内容。在测试团队修复并批准所有内容后，我们将更改合并回主干，并从特定于该版本的分支创建一个新标签。

因此，我们的想法是我们的分支和标签并没有真正直接参与持续集成。将分支代码合并回主干会自动使该代码成为 CI（持续集成）的一部分。我们通常只在分支中针对特定版本进行错误修复，因此我相信它并没有真正参与 CI 过程。相反，如果我们出于某些原因在一个分支中开始制作新的故事卡，那么我们不会将该分支分开太久。我们会尽快将其合并回主干。

没错，

我们在计划下一个版本时手动创建分支
我们为发布创建一个分支并修复该分支中的错误以防万一
一切顺利后，我们从该分支制作一个标签，该标签在逻辑上是不可变的
如果有一些修复/修改，最后我们将分支合并回主干

【讨论】：

【解决方案2】：

您可以使用 Team Foundation Server 2008 和 Microsoft Studio Team System 来完成源代码控制、分支和发布。

【讨论】：

我不认为这是对软件的抱怨。而是关于如何实践或持续集成的最佳实践。

【解决方案3】：

我很惊讶这不是重复的，但我找不到另一个。

好的，这就是交易。它们是两个独立但相关的问题。

对于构建管理，要点是您应该有一个自动的、可重复的构建，它从头开始重新构建整个软件集合，并一直到您的可交付配置。换句话说，您应该每次都有效地构建一个候选版本。许多项目并没有真正做到这一点，但我已经看到它烧人（读作“被它烧死”）太多次了。

持续集成表示，如果可能，每次代码发生重大更改事件（如签入）时，都应重复此构建过程。我已经完成了几个项目，其中这变成了每晚的构建，因为代码足够大，需要花费几个小时来构建，但理想的情况是设置您的构建过程，以便一些自动机制 --- 像蚂蚁脚本或制作文件 --- 仅重建受更改影响的部分。

您可以通过以某种方式为每个构建保留所有受影响工件的确切配置来处理提供特定版本的问题，这样您就可以将可重复的构建过程应用于您拥有的确切配置。（这就是为什么它被称为“配置管理”。）通常的版本控制工具，如 git 或 subversion，提供了识别和命名配置的方法，以便可以恢复它们；例如，在 svn 中，您可以为特定构建构建一个标签。您只需要保留一点元数据，以便了解您使用的配置。

您可能想阅读一本“实用的版本控制”书籍，当然 Martin Fowler 网站上有关 CI 和 Cruise Control 的内容是必不可少的。

【讨论】：

【解决方案4】：

长话短说：创建一个从主干复制的分支，然后在构建服务器上的该分支上签出/构建您的版本。

但是，使用 cc.net 以完全自动化的方式达到这一点并非易事。如果您愿意，我可以详细介绍我们的构建过程，但对于本次讨论来说可能过于细化。

我同意 Charlie 关于从头开始自动、可重复构建的观点。但我们不会全部为“持续”构建，仅针对 Nightly、Beta、Weekly 或 Omega (GA/RTM/Gold) 版本构建。仅仅是因为某些事情（例如生成文档）可能需要很长时间，并且为了持续构建，您希望向开发人员提供有关构建结果的快速反馈。

我完全同意保留确切的配置，这就是为什么分支发布或标记是必须的。如果您必须维护一个发布，即您不能只发布另一个主干副本，那么发布分支方法是可行的方法，但您需要熟悉合并。

【讨论】：

【解决方案5】：

发布管理远远超出持续集成。

在您的情况下，您应该使用 Cruise Control 自动制作标签，这样开发人员可以在您的增量构建发生时继续编码。

如果您的构建是增量的，这意味着您可以每 x 分钟触发一次（而不是每次提交，因为如果它们过于频繁，并且如果您的构建太长，则可能没有时间在下一次之前完成构建尝试发生）。 'x' 应该被剪裁为比编译/单元测试周期更长。

持续集成还应包括自动启动单元测试。

除此之外，完整的发布管理流程将涉及：

在认证服务器上的一系列部署
认证/UAT（用户验收测试）的完整周期
非回归测试
性能/压力测试
预生产（和并行运行测试）

在最终投入生产之前。

“发布管理”再次比“持续集成”复杂得多；）

【讨论】：