您的团队如何处理构建？
我们使用Cruise Control，但（由于缺乏知识）我们面临一些问题 - Code freeze in SVN - Build management
具体来说，如何在不断检查代码时如何提供特定版本？
通常，您能否讨论一下您在发布管理中使用的最佳实践？
答案 0 :(得分：14)
我非常惊讶这不是重复，但我找不到另一个。
好的，这是交易。它们是两个独立但相关的问题。
对于构建管理，关键点在于您应该拥有一个自动，可重复的构建，从头开始重建整个软件集合，并一直到您的可交付配置。换句话说，你应该每次都有效地建立一个候选版本。许多项目并没有真正做到这一点，但我已经看到它燃烧了人们（读“被它烧掉了”）太多次了。
持续集成表示，每当代码发生重大更改事件（如签入）时，应尽可能重复此构建过程。我已经完成了几个项目，每晚都会变成一个版本，因为代码足够大，需要花费几个小时来构建，但理想的是设置你的构建过程以便有一些自动机制 - 就像一只蚂蚁脚本或make文件---只重建受更改影响的文件。
您可以通过某种方式处理提供特定版本的问题，从而为每个版本保留所有受影响工件的确切配置，因此您可以将可重复构建过程应用于您具有的确切配置。 （这就是为什么它被称为“配置管理”。）通常的版本控制工具，如git或subversion，提供了识别和命名配置的方法，以便可以恢复它们;例如，在svn中，您可以为特定构建构建标记。您只需要保留一些元数据，以便了解您使用的配置。
您可能希望阅读其中一本“实用版本控制”书籍，当然，Martin Fowler网站上CI和Cruise Control的内容也很重要。
答案 1 :(得分：5)
请看马丁福勒的continuous integration: best pratices。
嗯，一年前我参加了一次related thread。您可能也觉得它很有用。 这就是我们如何做到的。
<强> [编辑]
我们正在使用Cruise Control作为集成工具。我们只处理trunk，这是我们案例中的主要Subversion存储库。当有可能发生复杂的冲突时，我们很少会为新的故事卡拉出一个新的分支。通常，我们为版本发布提取分支并从中创建构建并将其交付给我们的测试团队。同时我们继续干线工作，等待测试团队的反馈。一旦测试完毕，我们就会从分支创建一个标签，这在我们的案例中逻辑上是不可变的。因此，我们可以随时向任何客户发布任何版本。如果发布中存在错误，我们不会创建标记，我们会修复分支中的内容。在将所有内容修复并经过测试团队批准后，我们会将更改合并回主干，并从特定于该版本的分支创建新标记。
所以，我们的想法是我们的分支机构和标签并没有直接参与持续集成。将分支代码合并回主干会自动使该代码成为CI（持续集成）的一部分。我们通常在分支机构中针对特定版本执行错误修正，因此我认为它并不真正参与CI过程。相反，如果我们开始在一个分支中开始创建新的故事卡，那么我们就不会将该分支保持太长时间。我们尝试尽快将它合并回主干。
准确地说，
答案 2 :(得分：2)
发布管理远远超出持续集成。
在您的情况下，您应该使用Cruise Control自动创建一个标记，这样开发人员可以在进行增量构建时继续编码。
如果您的构建是增量的，这意味着您可以每隔x分钟触发一次（而不是每次提交，因为如果它们太频繁，并且如果您的构建太长，则可能没有时间在下一个构建之前完成构建尝试发生）。 'x'应该定制为比编译/单元测试周期更长。
持续集成还应包括自动启动单元测试。
除此之外，完整的发布管理流程将涉及：
在最终投入生产之前。
再次“发布管理”要比“持续集成”复杂得多;）
答案 3 :(得分：0)
长话短说：创建从主干复制的分支，并在构建服务器上的该分支上构建您的版本。
然而，使用cc.net以完全自动化的方式达到这一点并非易事。如果你愿意的话，我可以详细介绍一下我们的构建过程，但是对于这个讨论来说，它可能太精细了。
我同意查理关于从头开始进行自动，可重复的构建。但我们不会为“持续”构建做所有，仅针对Nightly，Beta，Weekly或Omega（GA / RTM / Gold）版本构建。仅仅因为某些事情（如生成文档）可能需要很长时间，而对于持续构建，您希望为开发人员提供有关构建结果的快速反馈。
我完全同意保留确切的配置，这就是为什么必须分支版本或标记。如果你必须维护一个版本，即你不能只发布另一个trunk版本，那么在发布方法上的分支是可行的方法，但你需要熟悉合并。
答案 4 :(得分：-2)
您可以使用Team Foundation Server 2008和Microsoft Studio Team System来完成源代码管理，分支和发布。