标签: ms-release-management

我正在为Visual Studio Team Services新版本管理系统的预览做准备.我的场景是一个经典的网站(ASP.NET 4.5),在VSTS中托管了一个Git repo.构建定义是成功的,如下所示:

它被设置为发布为可由Release Manager拾取的工件,如下所示:

在发布管理器端,我将该工件正确链接,如下所示:

在这里,您可以看到我的环境以及相关的任务(所有3个都是克隆)

当我运行发布时,构建发布很好,它连接到我的订阅但是当它试图找到包文件时,它在输出日志的第101行上有以下错误:

"没有找到使用搜索模式'C:\ a\4fe43dd1a***.zip'部署的文件"

这是完整的输出:

这是我卡住的地方,因为我假设通过VSTS的工件链接应该为我解决此路径.显然我在某个地方错过了一个重要的难题,但我尽可能地遵循了可用的文档.

如果有人有解决方案或能指出我正确的方向,我将不胜感激!

---编辑---

我使用文件选择器来选择Web部署包(见下文).我尝试使用root网站以及bin文件夹.两次尝试都会导致错误,指出:"没有找到使用搜索模式部署的文件'C:\ a\4fe43dd1a\Classic Website Definition\drop\ClassicWebsite\bin'"

---编辑2 ---

我使用以下MSBuildArguments向我的BUILD进程添加了一个MSBuild任务

/p:OutDir=$(build.stagingDirectory) /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true

在我的复制/发布工件任务中,我将输出限制为仅复制.zip文件.现在在我的RELEASE过程中,当我导航找到"Web部署包"时,"drop"文件夹为空.这是一个截图:

我想我正走在正确的道路上,我只需要帮助搞清楚我的BUILD任务,以便为我的RELEASE进程生成正确的工件.任何帮助,将不胜感激.

我正在尝试实现持续集成和持续部署到我的DEV Azure应用服务.我在Visual Studio Team Services上使用托管代理.我的发行版定义中的"将网站部署到Azure"步骤一直失败,并显示错误"找不到包含指定模式的包".有任何想法吗？

我们将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, …

我正在使用TFS版本管理来进行持续集成和部署.

我在部署期间使用migrate.exe来执行数据库迁移,当您从旧版本迁移到较新版本时,这非常有用.但是,当您想要部署旧版本的应用程序时,它会变得更加混乱.

基本上,保存上下文迁移的程序集必须知道如何从第3版转到第2版.通常,您使用要部署的程序集作为迁移的源,但在这种情况下,您必须使用已部署的程序集,因为他们是唯一知道如何从v3下载到v2的人.(版本2不知道v3甚至存在.)

我目前的计划是在部署期间以某种方式比较两个程序集.如果安装目录中的程序集包含"部署控制器"中的"更新"迁移,我首先需要在部署目录中的程序集中获取"最新"可用迁移,然后执行:

migrate.exe AssemblyInInstallationDir /targetMigration NewestFromAssemblyInDeploymentDir

在您正在升级到较新版本的"正常"部署方案中,您可以这样做:

migrate.exe AssemblyInDeploymentDir

这是一种合法的做法吗？我还没有考虑使用EF库来评估每个程序集中可用的迁移.还存在这样的事实的挑战:这些组件中的每一个都是"相同"的不同版本.我可能需要将它们加载到单独的应用程序域中,然后使用跨应用程序域通信来获取我需要的信息.

编辑

我创建了一个概念验证应用程序,它允许我列出可用的迁移到同一程序集的两个不同版本.这对整个过程至关重要,所以我认为值得记录.

该应用程序使用反射来加载每个程序集,然后使用System.Data.Entity.Migrations中的DbMigrator类来枚举迁移元数据.迁移的名称以时间戳信息为前缀,从而允许我对它们进行排序并查看哪个程序集包含"更新"的迁移集.

static void Main(string[] args)
{
    const string dllName = "Test.Data.dll";
    var assemblyCurrent = Assembly.LoadFile(Path.Combine(System.Environment.CurrentDirectory, string.Format("Current\\{0}", dllName)));
    var assemblyTarget = Assembly.LoadFile(Path.Combine(System.Environment.CurrentDirectory, string.Format("Target\\{0}", dllName)));

    Console.WriteLine("Curent Version: " + assemblyCurrent.FullName);
    Console.WriteLine("Target Version: " + assemblyTarget.FullName);

    const string contextName = "Test.Data.TestContext";
    const string migrationsNamespace = "Test.Data.Migrations";
    var currentContext = assemblyCurrent.CreateInstance(contextName);
    var targetContext = assemblyTarget.CreateInstance(contextName);

    var currentContextConfig = new DbMigrationsConfiguration
    {
        MigrationsAssembly = assemblyCurrent,
        ContextType = currentContext.GetType(),
        MigrationsNamespace = migrationsNamespace …

我正在使用VSTS构建来运行CI构建.此版本定义是相同的我所有的Git分支(主,开发,功能等).

我现在正尝试使用VSTS版本管理实现部署管道.我计划有两个不同的版本定义.一个用于功能分支,一个用于更重要的分支,如develop和master.功能分支的发布定义将更加轻量级.

我认为这是非常基本和平常的.实际上,这几乎是微软发布管理的典型用例中记录的内容.

对于这两个管道,我想将它们配置为使用"持续部署"触发器自动启动.当我选择此触发器时,我必须选择一个工件源.

不幸的是,工件源会获取来自给定构建定义(我的CI构建)的所有工件(无论分支).由于我对所有分支使用相同的CI构建定义,看起来我无法在"持续部署"中配置我的两个版本管道,并且仍然使用相同的构建定义作为工件源.

任何人都知道如何为多个版本定义共享相同的构建定义,但只为特定分支启动发布？在定义工件源时,有人知道通过分支过滤的方法吗？

如何在Visual Studio Team服务中的发布定义中重命名文件？是否有可用的内置或市场任务,如何实现？

回答:

1. 从市场中添加"内联PowerShell"任务

2. 在文本区域中输入以下PowerShell代码

   Param
   (
    [string]$pathToFileToRename
   )
   
   Rename-Item $pathToFileToRename NewName.txt
   

   Run Code Online (Sandbox Code Playgroud)

3. 例如,在参数文本框中输入任何必需的参数(您可以使用环境变量).

   pathToFileToRename $(System.DefaultWorkingDirectory)/somepath/CurrentName.txt
   

   Run Code Online (Sandbox Code Playgroud)

我正在使用TFS 2015 Update 2发布管理(即"发布"选项卡),我的构建将所需的输出放在文件共享放置位置.它看起来像:

/Drop
--> /App 1
--> /App 2
--> /App 3

我的发行版定义有一个Powershell任务来部署每个应用程序.这很好用,因为上面的每个应用程序(App 1,App 2,App 3)都被定义为他们自己的工件,当我在找到要执行的powershell脚本时调出Linked Artifacts对话框时,我得到了很好的路径选择.

问题是当VSOAgent在给定的部署服务器上进行部署时,它会为整个版本定义下载所有链接的工件 - 无论它们是否被使用.因此,如果我有一个引用App 1的Powershell任务,我也会下载App 2和App 3.

在我的例子中,我的构建产生了许多工件,其中只有20%被部署到任何给定的环境中.所以我下载了一些我不需要的东西.实际上,这意味着应该采取的措施(并且DID采用旧版本管理)或许5分钟现在需要20分钟才能下载工件.

有办法防止这种情况吗？

我们正在使用发布管理,TFS 2013(以前的InRelease),并且有很多我们想要删除的版本.问题是"删除"按钮始终显示为灰色.我们在这里失踪了什么？

在发布管理中使用Visual Studio测试任务时,发行版始终返回:

找不到与模式匹配的测试程序集

目前Test Assembly设置为:**\*test*.dll;-:**\obj\**

我尝试了多种默认设置,如$(System.DefaultWorkingDirectory)等.

我能够找到的文档要么不是现有的任务布局(例如Publish Build Artifacts屏幕不再包含Contents框),要么是针对Visual Studio 2015的内部部署,要么是特定于建立.

我已阅读并尝试以下内容:

• https://msdn.microsoft.com/Library/vs/alm/Release/getting-started/deploy-to-azure
• https://msdn.microsoft.com/Library/vs/alm/Release/author-release-definition/understanding-tasks
• https://msdn.microsoft.com/en-us/library/gg265783.aspx#Activity_RunTests
• http://blogs.msdn.com/b/visualstudioalm/archive/2015/07/31/dev-test-in-azure-and-deploy-to-production-on-premises.aspx
• http://blogs.msdn.com/b/visualstudioalm/archive/2015/05/29/testing-in-continuous-integration-and-continuous-deployment-workflows.aspx

更新: 我在构建中添加了一个步骤来复制和发布test.dlls.它们现在位于.由于缺少其他代码,它们都失败了,但它们都位于.

更新II: 我的3_Run_Tests.log文件包含以下线索:

调用测试类的初始化方法时出错...要运行与桌面交互的测试,必须将测试代理设置为作为交互式进程运行.

测试运行部署问题:未找到测试容器直接或间接引用的程序集或模块....

由于上述原因,我将接受@ eddie-msft的回答.

我正在尝试使用VSTS版本在发布时替换appSetting.Web上的所有帖子都参考旧版本管理工具或参考新版本,但提及替换令牌任务.这个任务不存在,所以我认为它是内置的.我已经设置了我的web.config(MyVar)并设置我的环境变量,但没有任何东西被替换.

这是我的发布:

我很抱歉,如果我是愚蠢的,但我无法解决这个问题,主要是因为过时的文档.

更新2:好的,经过几个人的帮助,我现在正走在正确的轨道上.我添加了Colin的ALM令牌化任务:https://marketplace.visualstudio.com/items ？ itemName = colinsalmcorner.colinsalmcorner-buildtasks

但是,它不起作用.

这里有几个屏幕截图: 请注意,在屏幕截图中,我知道它已被禁用.直到我能解决这个问题.

在下面的屏幕截图中,我看到只有几个位置可以选择令牌化发生的位置.这看起来是正确的还是我应该能够看到我想要替换令牌的Web.Config？

正如我所说,标记化没有用.

我尝试了几个更改,试图让它工作.

更改1:指向上面的acreen镜头中的zip文件.我的版本有效,但它没有将我的任何网站文件部署到Azure服务器.一个都没有.

更改2:指向另一个文件CustomerPortal.SetParams.xml

(注意:此时我只是尝试随机文件试图让任何东西工作)我的发布工作但没有发生关于标记化的事情.

这是我的日志的一部分:

正如您所看到的,即使发布成功,我网站上的所有文件都不存在:

任何帮助将是欣赏.