我对此主题进行了大量研究,但未能找到任何端到端解决方案来实现“使用TFS 2010构建一次并部署多个”。
基本上我正在考虑的是有一个构建定义,它将构建一个包含多个项目的解决方案(Web应用程序+数据库项目+ Web服务+报告),将输出放在drop文件夹中并从那里开始质量和版本手动决定将所有项目部署到各种环境(qa,ua,staging,production)。
我知道我可以修改构建过程模板以在构建之后立即部署多个项目,例如“构建主要部署到QA”,“构建主要部署到UA”等,可能基于变更集#或标签但这意味着每次都要建设。 我想要的更像是一个仪表板,它允许部署团队部署在QA中测试的精确构建,在UA环境中以及在生产后部署它之后的绿灯。当然,这意味着配置文件应该在部署时相应地更新。
我也在考虑定义一些实际上不构建任何内容的构建定义,而是将现有构建(基于版本)部署到特定环境,但至少可以说它看起来有点奇怪。
答案 0 :(得分:2)
这与我们使用的内容相近,我们已经构建模板来进行实际构建,并部署模板将输出部署到各种机器(这些模板可以设置为在预定时间运行,如夜间降至QA等,或者需求如UAT / live)。这些模板是从默认模板中进行了高度修改的,我们只是从构建中获取详细信息(或者在某些情况下,您可以采用最新的构建,例如冒烟测试环境),例如放置位置。
您在部署的计算机上需要一个可以处理部署的代理,但您可以根据需要安装任意数量的代理。
作为一个例子,你可以有一个构建,将你的应用程序构建到一个exe,以及一个模板,它接受exe并在你的目标上运行它(使用InvokeProcess)。如果您需要将同一个东西部署到另一个环境,您只需使用相同的放置位置,中提琴!
你得到的东西听起来并不奇怪,以这种方式处理它是有意义的。
答案 1 :(得分:1)
我知道这是一个迟到的回复,但自2012年以来情况发生了变化。微软现在已经设计了一个Release Management offering,它是从头开始设计的,可以实现一次构建,部署许多"。修改构建过程模板总是很麻烦。
答案 2 :(得分:0)
Daniel的回答几乎是获得像TeamBuild这样的构建系统来处理部署的标准方法。感觉有点奇怪,因为你正在将工具弯曲到另一个目的。它绝对可以工作。
另一种方法是获得与TFS / TeamBuild集成的纯部署工具。跨环境的部署是自然的,但是您有两个要管理的工具。