有人为自动部署成功实施了MS InRelease吗?

the*_*man 3 tfs visual-studio webdeploy tfs2013 ms-release-management

只是在企业应用程序中寻找对当前使用InRelease进行部署方案的任何人的反馈?

InRelease最近被微软收购,目前正在试用 http://www.microsoft.com/visualstudio/inrelease/ 据我所知,这将集成在未来版本的TFS中.

我一直在试用它一段时间,并有兴趣听取任何现有客户的反馈,无论是积极的还是消极的,包括以下信息:使用这个v的webdeploy/powershell等的优点/缺点.产品的稳定性.等等..

Dan*_*ann 9

我一直在谈论MS发布管理(又名InRelease)一个不少,在过去数个月.它很棒,从2013年11月13日起可以下载.

与传统的部署方法相比,它具有一些巨大的优势:

  • 大量用于部署软件的内置工具.它带有一堆开箱即用的东西,所以你不必乱用编写PowerShell脚本来设置IIS或启动Azure VM.工具系统是完全可扩展的,因此您可以插入所需的任何批处理文件,PowerShell脚本或可执行文件.它还会自动捕获运行的任何内容的输出,并将其附加到部署日志中.
  • 回滚功能.您可以定义部署失败时应采取的操作,这样您就可以确保错误部署永远不会关闭关键服务.
  • 配置文件管理.您可以参数化配置文件,然后使用版本管理指定应使用的值.这有助于减少(甚至消除)管理多个web/app.configs的噩梦.
  • 定义批准工作流程的能力.如果您希望能够让特定人员根据是否通过QA等来批准/拒绝版本,那么这是巨大的.
  • 发布路径定义.这与批准工作流程相关联 - 您可以对其进行设置,以便为发布过程的每个"阶段"设置环境 - DEV,QA,PROD等.然后,您可以设置哪些服务器是这些阶段的成员,您的软件应该通过这些阶段的顺序,以及谁负责批准/验证每个阶段.
  • 完全可追溯到发布过程 - 您可以看到您的软件当前在服务器上的哪些版本,何时到达,谁批准/拒绝它,所有部署操作的完整日志.它确实可以让您深入了解流程需要改进的地方.假设你有QA团队因为错误而失败了很多版本.您可以看到这一点,并回到您的开发人员那里说"嘿,伙计们,我们需要更好地进行自动化测试;当我们能够更早地发现这些缺陷时,我们正在淹没QA团队!"
  • 与TFS集成,因此您可以轻松设置持续部署.
  • Microsoft Test Manager集成.您可以将其设置为在发布完成后从MTM测试计划中运行自动化测试(例如编码的UI),因此如果您的任何测试失败,您可以自动使发布失败.

并且它将来会变得更好.发布管理团队在他们的积压工作中有一些非常酷的东西!