我当前的项目有 5 个独立的自动化构建，每次签入后都会启动：
单元测试（模拟数据库调用）：~6 分钟
集成测试（仅针对数据库）：~40 分钟
网站 1 UI（Selenium，从 UI 到DB）：~80 分钟
网站 2 UI1（Selenium，从 UI 到 DB）：~90 分钟
网站 2 UI2（Selenium，从 UI 到 DB）：~100 分钟
我们正在使用 Maven2、JUnit 和 Selenium。
我认为将大大减少集成测试时间的一种策略是将尽可能多的集成测试转移到单元测试中，并简单地使用集成项目来测试数据库的持久性。
我想知道您发现哪些策略有助于减少大型项目的构建时间。
我们的构建运行时间几乎相同，在 selenium 上可能略少（我会说大约 3x50 分钟的运行时间，在 firefox 上进行相同的站点测试，即和 opera）。我们的解决方案是投入更多的 cpu，我们有一个总共 7 个双核节点的集群竹环境。
我们发现，在与 web-container/selenium 测试不同的盒子上运行 selenium-rc 和浏览器可以显着改善 selenium 运行时。
我正在使用GNU make来自动化一切。视项目而定，需要 2 分钟到 30 分钟。
团队系统：一切都在 1 小时内
我假设您的项目由几个子项目组成。如果没有，您可能需要重构代码库以便它可以做到。通过这种方式，您可以选择仅构建整个应用程序的特定部分，测试单个部分，然后在解决您正在处理的子项目上的错误时运行您的集成测试。
我们使用 Hudson 构建了一个包含少量 Windows 服务、Web 服务和可执行文件的大型 C# 解决方案。通过 MSTest.exe 进行大约 800 次左右的测试，每次构建大约需要 12-15 分钟。由于 MSTest 很慢，因此测试占了很大一部分。
为了减少时间，我们试图限制通过 MSTest 运行的程序集的数量，因为设置和拆卸似乎需要一段时间。
编辑：我们的构建还部署到我们的证书环境，其中包括 Web 服务、Windows 服务、可执行文件和数据库部署。只是为了让您了解范围
Erlang Common Test - 主要关注系统测试而不是单元测试。
我们所有的自动化构建都是使用 Team City 完成的。
我们使用的最自动化的项目实际上是一个编译器。我们的测试套件包含大约 20000 个已编译和运行的测试查询，这些查询在每次签入时运行。这通常需要一个小时的时间，但是将完整的测试套件保存在构建机器上的 RAM 驱动器中（而不是每次都检查出来）将其减少到几分钟。
每天晚上触发第二次构建，运行这些相同的测试，但在 4 个不同的配置文件下，同时在 NCover 下运行，生成代码覆盖率报告。这个场景需要几个小时，这就是为什么它是作为夜间构建完成的。同时生成其他内部报告，以确保一切正常。
对测试套件本身的更新是单独触发的，并检出到 RAM 驱动器，为下一次运行做好准备。否则，检查测试会占用大部分构建时间。部分测试套件来自我们无法控制的远程 CVS 存储库，甚至在构建时间中查询更新会增加几分钟，因此这也在“更新测试”构建中完成。这种松散的耦合意味着我们不得不将这个项目的构建限制在一台机器上，但由于反馈如此之快，这不是一个大问题。
事实证明，在保持代码库的高覆盖率的同时尽可能快地保持“常规”测试构建非常有帮助。任何缓慢的测试（超过一秒左右）都已通过夜间构建。在我们的案例中，将测试保存在 RAM 驱动器中确实很有帮助，尽管我们的场景相当专业。我想模拟你的数据库是最接近的等价物。我的建议是通过删除任何“笨拙”或缓慢的测试来保持一个构建“精简和平均”，让快速响应知道您可能没有破坏任何东西。其他构建可以在单独的机器上运行，也可以在晚上运行，以保持快速构建的快速响应。
从角度来看，我们（对于另一个项目）最长的自动化构建有时需要一天以上的时间，尽管幸运的是它不需要定期运行。
不幸的是，在我当前的客户 BuildForge（来自 ClearCase SCC）：从一到三天不等。严重。我真的不知道他们在构建中做了什么，也不知道为什么要花这么长时间。