我想增强发布定义，这样我就不需要一个只启动Azure VM的独立环境 .
如果我们采用我们拥有测试，测试版， 生产环境 环境的场景 . 客户希望将应用程序安装在本地网络上的Beta和Production中 . 我们内部希望测试环境能够运行E2E测试，允许非技术人员在不需要VPN访问客户beta环境等的情况下运行应用程序 .
所以这里我们有环境，然后是代理运行的地方：
Test - Azure VM Beta - Client machine Production - Client machine
我们如何解决这个问题的方法是在客户端的计算机上安装VSTS代理，这样我们就可以在为该版本定义的Beta和Production环境中定位该代理队列 . 然后，我们通常构建Azure VM并将该代理队列作为测试环境的目标 .
我们不想24/7/365运行Azure VM . 但是，如果它没有运行，则它无法响应发布管理的请求 .
我所做的是创建一个名为 Start Test VM 和 Stop Test VM 的环境，它使用 Azure Resource Group Deployment 来启动和停止VM . 这两个额外的环境可以将其代理队列设置为 Hosted .
我想弄清楚如何将前3个环境组合成逻辑 Test ，而不是必须创建3个发布管理环境 .
Start Test VM - Hosted Test - Azure VM Stop Test VM - Hosted Beta - Client machine Production - Client machine
问题是，当我把它交给我们的一个PM甚至是我自己时，可能会相当丑陋和混乱，当我在3个月左右回来时想一想，“这个环境到底是什么？哦，它只是在那里启动/停止VM“ .
选项：
-
保持现状 - 保持原样，无法修复
-
我们可以在Azure VM上打开一个端口并使用Powershell远程处理 . 然后在托管代理或内部部署代理上运行以启动VM，然后部署应用程序，然后停止VM . - 我们真的不喜欢这个，因为部署与客户端内部部署不同 . 我们'd like each environments'任务是一样的，只是用不同的变量 .
2 回答
您可以使用“Azure PowerShell”和“Azure SQL数据库部署”任务来配置Azure VM和SQL，或调用其他脚本以在Azure VM上运行 .
没有任何方法可以为任务设置代理 . 您可以在VSTS User Voice上提交功能请求 .
另一种减少环境的方法是：如果部署链接到发布的每个构建，那么可以在构建定义中添加“Start Test VM”任务以在构建成功时启动VM并添加“Stop Test VM”任务进入“Beta”环境 .
我们目前已经确定的是继续使用
environment，这不是我认为的环境，而是更多在启动和/或关闭VM的发布管道中的stage. 我们在hosted代理上运行它，以便它可以启动VM并确保在environment上检查Skip artifacts download.对于持续集成构建，我们设置一个链，以便VM启动，CI
environment开始，然后VM停止 . 然后根据需要在链上手动部署剩余的environments.所以这是一个例子：
启动CI VM
CI
停止CI VM
Beta
生产环境
以下是截至2016.06.27的发布管理中的外观图像：
我把单引号放在
environment左右，因为我认为我同意this user voice request，它's really more of a stage in the release pipeline. Much like database development, the logical and the physical don' t必须映射1到1 .