代码之家  ›  专栏  ›  技术社区  ›  mmacaulay

NAnt与数据库集成测试,最终实现持续集成

  •  2
  • mmacaulay  · 技术社区  · 17 年前

    我一直在探索在一些Nant构建脚本中运行集成测试的不同策略。通常,许多不同的脚本被链接在一个具有单独目标的整体构建中:阶段化(构建一个阶段化版本,如构建)、构建(只构建东西)、集成(构建东西并运行集成测试)。这工作得相当好,构建目标作为集成目标运行大约需要三分之一的时间,而且时间并不长,所以我不觉得自己不愿意经常运行它。

    另一方面,集成目标需要足够长的时间,我不想经常这样做——最好是在我准备好部署之前。这似乎是一个合理的策略吗?IOW,我做得对吗?

    计划最终将此项目转移到持续集成。我是整个持续集成的新手,但我想我理解“破坏构建”的概念,所以我想知道为了充分利用它,有哪些好的做法可以借鉴?

    任何关于这个主题的好的阅读来源也将受到赞赏。谢谢!

    3 回复  |  直到 17 年前
        1
  •  3
  •   SaaS Developer    17 年前

    是的,你走在正确的道路上。您现在需要做的是将您的nant目标连接到自动化流程。我建议使用Team City或Cruise Control作为您的CI工具。一旦您完成了自动化服务器设置,您就可以在每次签入时运行构建和单元测试(持续集成)。然后,您的集成测试可以在晚上或周末运行,因为它们通常需要更长的时间才能运行。如果你的集成测试成功,那么你就可以有一个部署到QA或其他服务器的作业。

        2
  •  2
  •   Aaron Palmer    17 年前

    听起来你已经走了99%的路。我的建议是,直接投入并开始做这件事。通过真正冒险去做,你会学到更多,而不是思考你是否做得对。

    我的公司目前正在使用CruiseControl,我个人认为它很棒。

        3
  •  1
  •   Community Mohan Dere    9 年前

    查看此相关帖子 What is a good CI build process?

    你走在正确的道路上。如果你使用的是一个不错的CI工具,你应该能够将每个设置设置为一个单独的项目,从而触发链中的下一步。..即成功的构建会触发测试,从而触发部署,进而触发集成等

    这样,你最真实的“突破”就可以说阻止了这条线。

    我们使用CruiseControl进行构建、单元测试、配置和部署、运行集成测试和代码覆盖率、运行验收测试以及打包发布。这是一个由大约8个web服务和十几个数据库组成的系统,所有这些数据库都具有相互关联的配置和部署依赖关系,可以跨多个具有不同配置的环境(从单个盒子到每个组件的冗余盒子)