Azure为多个项目持续部署

Question

我创建了一个Azure Web站点并将其连接到Visual Studio Online,这会自动设置一个连续的部署版本(根据此页面).

最初这适用于一个项目的解决方案,但现在我添加了一个Web API项目作为后端.这个名称是按字母顺序排列的两个项目中的第一个,所以现在它是唯一一个在签入文件时构建和部署的项目.这导致了我的问题:

如何修改默认的持续部署构建以部署两个应用程序？

我确信它必须对构建模板或参数或构建使用的发布配置文件进行相当简单的更改.唯一的问题是我不知道:A)如何在默认TfvcContinuousDeploymentTemplate.12.xaml构建模板中更改这些设置,以及B)如何修改在持续部署构建中使用的发布配置文件.

我已经从Visual Studio中手动发布了这两个项目,并按照本答案中的说明将它们部署到正确的位置.我右键单击每个项目,单击发布,然后选择"Microsoft Azure Web Apps"发布目标(在填写所有设置之后)将发布配置文件添加到我的项目中,并允许我按照我想要的方式手动部署它们.

遗憾的是,似乎没有办法重新上传这些发布配置文件,以便可以在CD版本中使用它们.我已将它们检查到源代码控制中,我只需要知道如何使用CD构建来使用它们.我怎样才能做到这一点？

Answer 1

再次阅读我的问题中的第一个链接后，我注意到您可以编辑构建定义（或模板）以指向您要使用的发布配置文件：

部署设置路径：Web 应用程序的 .pubxml 文件的路径，相对于存储库的根文件夹。云服务被忽略。

不幸的是，这两者都不起作用，并且只允许您指定一个发布配置文件。据推测，即使指定此参数有效，构建仍然只会按字母顺序部署第一个应用程序。

这让我想到了这个问题和答案，这表明 Azure/TFVC 持续部署只需使用 MSBuild 的普通 Web 部署参数即可工作。查看我在 Visual Studio Online 中构建的诊断日志证明情况确实如此；以下是相关论点：

C:\Program Files (x86)\MSBuild\14.0\bin\amd64\msbuild.exe /p:DeployOnBuild=true /p:CreatePackageOnPublish=true /p:DeployIisAppPath=mysitename

因此，根据该问题，要使用特定的发布配置文件，您只需在构建定义中设置其他必要的 MSBuild 参数即可：

每个项目都需要有一个名为“publishprofilename.pubxml”的发布配置文件，在本例中，已签入源代码管理。我发现不需要用户名（即前面带有美元符号的站点名称），但不幸的是需要密码字符串。如果不包含它，您会在构建中收到如下错误：

Web 部署任务失败。（使用 Web 管理服务连接到远程计算机（“[mysitename].scm.azurewebsites.net”），但无法授权。

我不需要其他参数，但必须包含密码似乎并不理想。默认部署设置（不使用发布配置文件）必须以某种方式使用该密码进行授权，但我不知道如何进行。

因此，在进行此更改后，我导航到 [mysitename].azurewebsites.net，看起来仍然只部署了 Web API 项目。但是，通过转到该站点的控制台并输入，dir D:\home\site\wwwroot我可以看到这两个项目实际上正在部署。只是这两个项目都被部署到站点的根目录，位于D:\home\site\wwwroot. 每个发布配置文件中的设置DeployIisAppPath都不同，但这些值将被忽略。这是因为/p:DeployIisAppPath=mysitenameMSBuild 的参数（如上所述）会覆盖发布配置文件 *.pubxml 文件中的任何设置，如本博客文章PropertyGroup中所述。

我发现，Azure/TFVC 的持续部署过程是通过InitializeContinuousDeployment在 TfvcContinouslyDeploymentTemplate.12.xaml 构建模板中紧接该RunMSBuild活动之前进行构建活动来实现的。这将采用您在生成定义中指定的 MSbuild 参数，并将部署到 Azure 所需的参数附加到这些参数中。不幸的是，这主要是硬编码的，这意味着它始终为解决方案中的所有 Web 项目指定单个部署路径。您无法单独使用发布配置文件将每个 Web 应用程序部署到不同的位置。

因此，一种解决方法是向每个项目添加BeforeBuildMSBuild 目标之类的内容，以覆盖DeployIisAppPath. 这样做的问题是，发布配置文件中指定的并在发布向导中看到的路径将不再是实际用于部署的路径。

所以我采用的解决方案稍微好一些；这就是我们在新西兰所说的“huckery”。

基本上我在和活动InvokeMethod之间添加了一个构建活动。本次活动的论据如下：InitializeContinuousDeploymentRunMSBuild

DisplayName:
Configure build for using publish profiles (removes DeployIisAppPath MSBuild parameter)

GenericTypeArguments:
System.String

MethodName:
SetValue

TargetObject:
AdvancedBuildSettings

Parameters:
Direction:      Type:       Value
In              String      "MSBuildArguments"
In              String      String.Join(" ", AdvancedBuildSettings.GetValue(Of String)("MSBuildArguments", String.Empty).Split(New String() {" "}, StringSplitOptions.RemoveEmptyEntries).Where(Function(s) Not s.StartsWith("/p:DeployIisAppPath=")))

这样做的DeployIisAppPath作用是从 MSBuild 命令行参数列表中完全删除该参数，以便它不会覆盖发布配置文件中的相同属性。如果您可以直接附加到命令行，而不是搞乱拆分和连接字符串/p:DeployIisAppPath=""，那就更好了，但这只是将属性设置为空字符串，然后您会收到错误：

未为“ConcatFullServiceUrlWithSiteName”任务提供所需参数“SiteAppName”的值

就像我说的，虽然很便宜，但它是一个解决方案，允许您将多个 Web 项目持续部署到 Azure，只需对默认设置进行最少的更改。