powershell - 发布管理 vNext 组件部署瓶颈

Question

我们将 Release Management 2015 与 vNext 发布模板一起使用。我们为应用程序的每个部分部署了一个基于 Powershell DSC 的组件，事实上，我们部署了两个不同的应用程序，它们正在积极开发中，并且通常几乎同时部署。

我们在部署过程中经常遇到以下错误:

OperationFailedException: New deployment is not allowed as an another deployment is in progress. Retry the deployment after sometime.

完整的堆栈跟踪显示错误不是来自 Powershell 本身，而是来自负责在目标机器上执行 powershell 脚本的 Release Management 系统:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Microsoft.TeamFoundation.Release.Common.Helpers.OperationFailedException: New deployment is not allowed as an another deployment is in progress. Retry the deployment after sometime.
   at Microsoft.TeamFoundation.Release.EnvironmentProvider.OnPrem.Implementation.OnPremDeploymentProvider.ReadDeploymentResponse(DeploymentResponse response)
   at Microsoft.TeamFoundation.Release.EnvironmentProvider.OnPrem.Implementation.OnPremDeploymentProvider.RunScript(String scriptPath, String configurationPath, MachineSpecification machine, StorageSpecification storage, Dictionary`2 configurationVariables)
   at Microsoft.TeamFoundation.Release.MonitorServices.Dsc.OnPrem.OnPremDeploymentActions.InvokePlatform(String activityId, MachineSpecification machineSpecification, StorageSpecification storageSpecification, String scriptPath, String configurationPath, Dictionary`2 configurationVariables)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at Microsoft.TeamFoundation.Release.DeploymentAgent.Services.Deployer.Dsc.DscComponentInstaller.InvokeMethodByReflection(String methodArguments)

上述错误导致整个部署失败，我们被迫重试阶段或整个部署以使其完成。

有两种情况会导致这种情况:

两个发布模板同时在同一目标服务器上执行它们的 powershell 脚本

单个发布模板具有并行控制流，其中包含两个不同的组件，它们都在同一目标服务器上执行脚本

换句话说，Release Management 用于在远程服务器上执行 powershell 脚本的机制似乎一次只能执行一个脚本，并且无法等待/等待其他人完成。

如果有问题的脚本主动修改正在执行它的服务器，那么这种/排序是有意义的，但在我们的例子中，服务器基本上充当运行脚本的暂存区。脚本的“真实”目标与执行 powershell 的服务器无关。

除了每个服务器同时部署的组件(哇)之外，这里还有什么工作？这似乎是一个重大疏忽，它让我认真考虑完全放弃发布管理。

Answer 1

正如我在 another post 中解释的那样今天，MS Release Management 的部署方式有点违反直觉:它不只是使用 PSRemoting 对目标服务器执行 Powershell 部署脚本，而是使用 PSRemoting 在目标服务器上安装 Windows 服务 (VisualStudioRemoteDeployer.exe)。此服务然后在本地运行您的部署脚本，并且 MSRM 服务器定期轮询此 Windows 服务(请参阅 here )以查看它是否已完成部署。

我怀疑这个奇怪的设置与避免 double-hop issue 有关。 - 以便它允许您的脚本从目标服务器到另一台服务器进行第二跳，例如用于网络服务调用。

无论如何，此 Windows 服务可能会形成瓶颈，因为每台服务器只能运行一个这样的实例 - 因此，将组件并行部署到同一台服务器的事实似乎会发生冲突。

我认为您的问题源于您选择了“服务器基本上充当运行脚本的临时区域”的设置 - MS Release Management 2013/2015 在这种情况下效果不佳(如您所见)，您应该真正将组件直接部署到需要安装它们的目标服务器上，从而避免临时区域瓶颈。

next version of MS Release Management将使用部署代理作为一个中转点，组件将从中部署到其他服务器。这有助于减少您的防火墙必须允许的 MS Release Management 和目标服务器之间的连接数(这可能是您选择临时区域设置的原因)，同时仍然允许并行(或至少排队)部署。