NAnt 与数据库集成测试，以及最终的持续集成
我一直在探索在一些 Nant 构建脚本中运行集成测试的不同策略。 通常，许多不同的脚本链接在一个具有单独目标的整体构建中：暂存（构建暂存版本，如构建）、构建（仅构建内容）、集成（构建内容并运行集成测试）。 这工作得相当好，构建目标大约需要集成目标运行时间的三分之一，而且时间也不是很长，所以我发现自己不愿意经常运行它。
另一方面，集成目标需要足够长的时间，我不想经常这样做 - 最好是在我准备好部署之前。 这看起来是一个合理的策略吗？ IOW，我做得对吗？
计划最终将该项目转移到持续集成。 我对整个持续集成这件事很陌生，但我想我理解“打破构建”的概念，所以我想知道有哪些好的实践可以借鉴以充分利用它？
任何关于这个主题的好的阅读资源也将不胜感激。 谢谢！
I've been exploring different strategies for running integration tests within some Nant build scripts. Typically a number of different scripts are chained in one monolithic build that has separate targets: staging (build a staging version, like build), build (just build the stuff), integration (build the stuff and run the integration tests). This works reasonably well, the build target takes about a third of the time to run as the integration target and it's not painfully long so I don't find myself disinclined to run it frequently.
The integration target on the other hand takes long enough that I don't want to do it very often - ideally just before I'm ready to do a deploy. Does this seem like a reasonable strategy? IOW, am I doing it right?
The plan is to eventually move this project to Continuous Integration. I'm new to the whole Continuous Integration thing but I think I understand the concept of "breaking the build" so I'm wondering what are some good practices to pick up in order to make the most of it?
Any good sources of reading on this subject would be appreciated as well. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，您走在正确的道路上。 您现在需要做的是将您的 nant 目标连接到自动化流程。 我建议使用 Team City 或 Cruise Control 作为 CI 工具。 一旦您完成了自动化服务器设置，您就可以在每次签入时运行构建和单元测试（持续集成）。 然后，您的集成测试可以在晚上或周末运行，因为它们通常需要更长的时间来运行。 如果您的集成测试成功，您就可以将作业部署到某些 QA 或其他服务器。
Yes, you are on the right track. What you need to do now is to hook up your nant target to an automated process. I recommend using either Team City or Cruise Control for as your CI tool. Once you have your automated server setup you can run your build and unit tests on each check in (Continuous Integration). Your integration tests could then run at night or over the weekend since they typically take longer to run. If your integration tests are successful, you can then have a job that will deploy to some QA or other server.
听起来你已经完成了 99% 的任务。 我的建议是全身心投入并开始做。 通过实际尝试并付诸实践，你会学到比思考自己是否做对了更多的东西。
我的公司目前正在使用 CruiseControl，我个人认为它很棒。
Sounds like you're 99% of the way there. My advice is to just dive in and start doing it. You'll learn a lot more by actually taking the plunge and doing it than by thinking about whether you're doing it right.
My company is currently using CruiseControl and I personally think it's great.
请参阅此相关主题什么是好的 CI 构建过程？
你走在正确的轨道上。 如果你使用的是一个不错的 CI 工具，你应该能够将每个设置设置为一个单独的项目，触发链中的下一步...即成功的构建触发测试，触发部署，触发集成等
。 “break”可以说是停止了线路。
我们使用 CruiseControl 来构建、单元测试、配置和部署、运行集成测试和代码覆盖率、运行验收测试以及打包发布。 这是一个由 8 个左右的 Web 服务和十几个左右的数据库组成的系统，所有这些都具有跨多个环境的相互关联的配置和部署依赖关系，具有不同的配置（从单个盒子到每个组件的冗余盒子）
See this related thread What is a good CI build process?
You are on the right track. If you're using a decent CI tool, you should be able to set each setup up as a separate project that triggers the next step in the chain... i.e. sucessfull build triggers tests which trigger deployment which triggers integration etc
This way your ealiest "break" stops the line so to speak.
We use CruiseControl to build, unit-test, configure and deploy, run integration tests and code coverage, run acceptance tests, and package for release. This is with a system of 8 or so web services, and a dozen or so databases, all with interralated configuration and deployment dependencies with across multiple environments with different configurations (anythin from single boxes to redundent boxes for each component)