发布管理vNext组件部署瓶颈

Question

我们将Release Management 2015与vNext发布模板一起使用.我们为应用程序的每个部分都提供了基于Powershell DSC的组件部署,事实上,我们正在部署两个不同的应用程序,这些应用程序处于活动开发阶段,并且通常几乎同时部署.

我们经常在部署期间收到以下错误:

OperationFailedException:不允许进行新部署,因为另一个部署正在进行中.有一段时间后重试部署.

完整的堆栈跟踪显示错误不是来自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)

上述错误导致整个部署失败,我们被迫重试阶段或整个部署以完成它.

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

1. 两个版本模板同时在同一目标服务器上执行其PowerShell脚本
2. 单个版本模板具有并行控制流,其包含两个不同的组件,这两个组件都在同一目标服务器上执行脚本

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

如果有问题的脚本主动修改它正在执行的服务器,那么这种类型/ sorta是有意义的,但在我们的例子中,服务器基本上是一个运行脚本的暂存区域.脚本的"真实"目标与PowerShell碰巧正在执行的服务器无关.

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

Answer 1

我在远程服务器上运行Powershell脚本时遇到了问题.我最终走的路线略有不同.相反,我只是用Invoke-Command块运行一个普通的Powershell命令.我相信你应该能够同时运行它.

Function Get-PSCredential($User,$Password) {
    $SecPass = ConvertTo-SecureString -AsPlainText -String $Password -Force
    $Creds = New-Object System.Management.Automation.PSCredential -ArgumentList $User,$SecPass
    Return $Creds
}    

$credential = Get-PSCredential -User $deployUser -Password $deployPass
$session = New-PSSession YourServerName -Credential $credential

Invoke-Command -Session $session -ScriptBlock {
    # do your work here
}

如果您作为可以访问该计算机的服务帐户运行,您应该能够消除凭证内容并且只需使用

$session = New-PSSession YourServerName

我本周才开始使用发布管理,所以这似乎是在这么短的时间内完成的最佳方式.

此外,如果您以前从未使用Invoke-Command过,脚本块中的所有内容实际上都在其自己的范围内,因此-ArgumentList如果您有任何变量,则需要将变量传递给它.如果您对此有任何疑问,请查看此文章.

Answer 2

正如我今天在另一篇文章中所解释的，MS Release Management 的部署方式有点违反直觉：它不是仅使用 PSRemoting 对目标服务器执行 Powershell 部署脚本，而是使用 PSRemotingVisualStudioRemoteDeployer.exe在目标服务器上安装 Windows 服务 ( ) 。然后，该服务在本地运行您的部署脚本，并且 MSRM 服务器定期轮询该 Windows 服务（请参阅此处）以查看它是否已完成部署。

我怀疑这个奇怪的设置与避免双跳问题有关- 因此它允许您的脚本从目标服务器到另一台服务器进行第二跳，例如用于 Web 服务调用。

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

我认为您的问题源于这样一个事实：您选择了一个设置，其中“服务器基本上充当运行脚本的暂存区域” - MS Release Management 2013/2015 在这种情况下表现不佳（正如您所发现的），您确实应该将组件直接部署到需要安装它们的目标服务器，从而避免临时区域瓶颈。

MS Release Management 的下一版本将使用部署代理，该代理将作为组件部署到其他服务器的暂存点。这有助于减少防火墙上允许的 MS Release Management 和目标服务器之间的连接数量（这可能是您选择暂存区域设置的原因），同时仍然允许并行（或至少排队）部署。