我一直在探索在一些 Nant 构建脚本中运行集成测试的不同策略。通常，许多不同的脚本链接在一个具有单独目标的整体构建中：staging（构建一个暂存版本，如 build）、build（只是构建东西）、集成（构建东西并运行集成测试）。这工作得相当好，构建目标需要大约三分之一的时间作为集成目标运行，而且时间不长，所以我发现自己并不不愿意经常运行它。
另一方面，集成目标需要足够长的时间，以至于我不想经常这样做——最好是在我准备好进行部署之前。这看起来是一个合理的策略吗？IOW，我做得对吗？
计划是最终将此项目转移到持续集成。我是整个持续集成的新手，但我想我理解“打破构建”的概念，所以我想知道为了充分利用它，有哪些好的实践可以学习？
任何有关此主题的良好阅读资源也将不胜感激。谢谢！
是的，你在正确的轨道上。您现在需要做的是将您的 nant 目标连接到一个自动化过程。我建议使用 Team City 或 Cruise Control 作为您的 CI 工具。完成自动化服务器设置后，您可以在每次签入时运行构建和单元测试（持续集成）。然后，您的集成测试可以在晚上或周末运行，因为它们通常需要更长的时间才能运行。如果您的集成测试成功，那么您就可以拥有一项将部署到某个 QA 或其他服务器的作业。
听起来你已经完成了 99% 的工作。我的建议是潜入并开始做。通过实际尝试并去做，而不是思考自己是否做对了，你会学到更多。
我的公司目前正在使用 CruiseControl，我个人认为它很棒。
请参阅此相关线程什么是好的 CI 构建过程？
你在正确的轨道上。如果您使用的是体面的 CI 工具，您应该能够将每个设置设置为一个单独的项目，以触发链中的下一步......即成功构建触发测试触发部署触发集成等
这样，您最简单的“休息”就可以停止生产线。
我们使用 CruiseControl 来构建、单元测试、配置和部署、运行集成测试和代码覆盖率、运行验收测试以及打包发布。这是一个由大约 8 个 Web 服务和十几个数据库组成的系统，所有这些都具有相互关联的配置和部署依赖关系，并且跨具有不同配置的多个环境（从单个框到每个组件的冗余框）