我正在构建一个 CI 服务器，并且非常希望获得真实的体验，以及人们正在使用什么的概述。
那么，您的构建过程是什么？有没有类似的东西：
另外，您的完整构建过程使用什么？你使用类似的东西：
分享！ ;)
【问题讨论】：
我们在最近的 CITCON 北美（持续集成和测试会议）上进行了类似的对话，我们都分享了我们的经验，并尝试制定从简单 CI 到非常完善的 CI 和发布系统的路线图。
原始会议记录是here。连同 Flickr photostream。 urbancode 博客也提供cleaned up version。
澳大利亚人在布里斯班 CITCON 上重新讨论了该主题，并提供了 pencast
希望其中一些资源有用。
【讨论】：
在我之前的项目中，我们曾经有两个 luntbuild 服务器和一个 SVN 服务器。
第一台 luntbuild 机器用于构建项目 - 每次提交的增量构建 + 单元测试，然后在夜间清理构建 + 单元测试 + 完整的安装打包。
第二台 luntbuild 机器被用作集成测试的测试平台。第一台机器完成夜间安装后，它会立即进行安装，自行部署并运行全套集成测试（swing gui 的基于 junit 的驱动程序），因此每天早上测试工程师都会安装一份健全性检查报告，以便他们决定是否要采用新版本。
【讨论】：
构建过程 - 我们有 4 个当前活跃的大型代码库分支，我们持续运行构建。对于每个分支，我们将构建分为两个阶段：
我们的构建过程由 Zed Builds And Bugs 协调，包括跨 Windows、Linux、AIX、HP 和 Solaris 的 Ant、Make、Maven、JUnit、Findbugs、shell 脚本（历史）。
我们目前正在收集更多历史趋势和统计数据，以便我们可以从更高的层面了解开发过程的进展情况。
【讨论】：
我们将 CruiseControl.net 与 nant 结合使用作为我们的 CI 服务器。大多数构建（我们大约有 30 个构建）都是在更改时触发的。一些不太重要的重型构建每晚只触发一次，这也适用于清理大部分正常构建的维护构建。
对于我们的 C/C++ 代码构建，我们使用了一个专有的构建系统，该系统能够将代码构建分发到公司中可用的每台机器（如 IncrediBuild，但更加灵活）。对于我们的 C# 构建，我们直接调用 devenv.com，但我们使用 NUnit 来运行单元测试。我们的 C++ 单元测试使用我们自己的框架，运行它们会产生与 NUnit 非常相似的 xml。对于一些额外的代码检查，我们每晚运行 pclint。目前还没有完成代码覆盖，有点遗憾。
我们还使用该系统来准备我们产品的最终版本。这只是第一步，之后还需要一些手动操作。
【讨论】：
在我的情况下（内部设计/构建/支持的 CB 系统），提交给给定 CB 配置所针对的树中的 VCS 会自动将 CB 请求排队（在 CB 运行时到达的多个请求会折叠到一个，它将在当前 CB 流程完成后立即运行）。
每个 CB 实例通过执行其配置的构建和测试步骤来响应 CB 请求（将它们并行部署到由所有 CB 实例共享的分布式服务器“云”），记录构建和测试结果，偶尔（不超过配置的频率）启动“重度测试”（可能会运行很长时间并且不会阻止即将到来的 CB 请求——重度测试被完全分叉，尽管日志非常清楚地明确反对他们运行了哪个版本）。
“同步到头”（“头”在其他 VCS 中将是“主干”；-），对于不属于 CB 跟踪的树的一部分的依赖项，可能每次都会发生（这些将是轻量级的，非-生产关键，或实验构建），或仅在非常明确的集成请求上（这是另一个极端，对于生产关键的构建/项目的“发布分支”），或具有中等容忍度。
我认为，这不是发布工程实践的最高点，但在它的选择范围内，它对我们非常有效，适用于非常多样化的关键性、依赖性严重性等的各种各样的项目；-)。
【讨论】：
Jenkin 是持续集成 (CI) 的最佳工具。 CI 只不过是频繁地将代码集成到您的存储库 (SCM) 中。此外，将 SCM 集成到 jenkins 中以构建您的代码。
您可以在 jenkins 中设置轮询频率。这样，每当在 SCM 中进行更改并提交时，Jenkins 都会尝试进行构建。这种方式是可行的.. 持续集成。
【讨论】：