10

您的团队如何处理构建？
我们使用 Cruise Control，但是（由于缺乏知识）我们面临一些问题 - SVN 中的代码冻结 - 构建管理
具体来说，当代码不断被签入时，如何使特定版本可用？

一般来说，您能讨论一下您在发布管理中使用的最佳实践吗？

4

5 回答 5

14

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

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

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

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

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

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

于 2009-01-07T04:38:19.503 回答
5

查看Martin Fowler的持续集成：最佳实践。

好吧，我设法找到了一个相关的线程，我在一年前参与了。您可能会发现它也很有用。这就是我们如何做到的。

[已编辑]

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

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

恰恰，

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

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

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

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

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

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

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

在最终投入生产之前。

同样，“发布管理”比“持续集成”复杂得多；）

于 2009-01-07T05:19:39.763 回答
0

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

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

我同意查理关于从头开始自动、可重复构建的观点。但我们并不为“连续”构建做所有事情，只为每晚、测试、每周或欧米茄（GA/RTM/黄金）版本构建。仅仅是因为某些事情，例如生成文档，可能需要很长时间，并且对于持续构建，您希望向开发人员提供有关构建结果的快速反馈。

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

于 2009-01-07T05:12:40.340 回答
-2

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

于 2009-01-07T04:30:22.797 回答