我正在构建一个CI服务器，非常感谢您获得真实的体验，以及对人们使用什么的概述。您的持续集成如何工作？
那么，你的构建过程是什么？有什么样：
而且，什么是您的完整的构建过程使用？你使用类似：
分享！ ;）
我们在最近的CITCON北美地区（持续集成和测试会议）进行了类似的对话，我们都分享了我们的经验，并试图将简单CI到非常建立的CI和发布系统的路线图组合在一起。
原会议记录是here。随着Flickr photostream。 A cleaned up version也可以在urbancode博客上找到。
澳大利亚人重新考虑了本议题CITCON布里斯班的一个pencast可用
希望这些资源的一部分是有用的。
在我的情况（一个内部的设计/建造/ CB支持系统），提交到VCS在由给定的CB配置目标树自动排队一个CB请求（在CB运行时到达的多个请求会被合并为一个，这会在当前的CB过程完成后立即运行）。
每个CB实例通过执行它配置要执行的构建和测试步骤来响应CB请求（将它们并行分发到由所有CB实例共享的分布式服务器的“云”），记录构建和测试结果，偶尔（不会比配置的频率更频繁）启动“严重测试”（这可能会运行很长时间，并且不会阻止即将到来的CB请求 - 重度测试会完全分离，尽管日志非常清晰他们跑哪个版本）。可能会发生每次都会发生的情况，这些依赖项不是由CB跟踪的树的一部分（这些将是轻量级的，非生产关键型或实验性构建），或者仅限于非常明确的集成请求（对于生产关键的构建/项目来说，“发布分支”是另一个极端），或者具有中间容忍度。
我认为，不是发布工程实践的顶峰，而是在它的选择范围内，它对我们来说非常适合各种各样的非常多样化的关键项目，依赖性沉重，＆c ;--）。
在我以前的项目中，我们曾经有两台luntbuild服务器加上一台SVN服务器。
第一台luntbuild机器用于构建项目 - 增量构建+每次提交的单元测试，然后清理构建+单元测试+在夜间完成安装包装。
第二个luntbuild机器被用作集成测试的测试装备。一旦第一台机器完成了夜间安装，它就会选择它，将其部署在自身上，并运行整套集成测试（基于junit的swing gui驱动程序），因此每天早上测试工程师将获得一个安装一份完整性检查报告，以便他们可以决定是否要采取新的构建。
我们使用CruiseControl.net作为CI服务器与nant的组合。大多数构建（我们有大约30个构建）都是在变化时触发的。一些不太重要的重型版本每晚只触发一次，这也适用于维护版本，它可以清除大部分正常版本。
对于我们的C/C++代码构建，我们使用的专有构建系统能够将代码构建分发给公司内可用的每台机器（如IncrediBuild，但更灵活）。对于我们的C＃构建，我们直接调用devenv.com，但我们使用NUnit来运行单元测试。我们的C++单元测试正在使用我们自己的框架，在xml中运行它们的结果非常类似于NUnit's。对于一些额外的代码检查，我们每天晚上运行pclint。目前，尚未完成代码覆盖，这有点令人遗憾。
我们也在使用该系统来准备我们产品的总决赛版本。这只是第一步，之后仍然需要一些手动操作。
构建流程 - 我们目前有4个活动的大型代码库分支，我们持续运行构建。对于每一个分支，我们将建立分为两个阶段：运行后，每一个承诺，使我们可以得到关于断码，或折断测试反馈
我们的构建过程由Zed Builds And Bugs协调，包括蚂蚁，制作时，Maven，JUnit中，FindBugs的，shell脚本（历史），跨Windows，Linux和AIX，HP和Solaris。
我们目前正在包括更多的历史趋势和统计数据汇总，以便我们可以从更高层次看到开发流程的进展情况。
Jenkin是连续集成（CI）的最佳工具。 CI不过是经常在代码库（SCM）中集成代码。此外，将SCM集成到jenkins中以构建代码。
您可以在jenkins中设置轮询频率。因此，无论何时在SCM中进行更改并提交，Jenkins都会尝试进行构建。这种方式是有效的。持续整合。
请参阅：http://stackoverflow.com/questions/102902/what-is-a-good-ci-build -process – Shog9 2009-07-20 06:25:41
@ Shog9：你提到的问题是在更抽象的层次上讨论CI（我敢说* meta *？），而这个问题则要求具体的实现细节。我认为他们有足够的差异来保持这个开放。 – Treb 2009-07-20 07:32:51