使用打包构建和发布配置文件的 Azure DevOps 发布管道
Azure DevOps Release Pipeline using Packaged Build and Publish Profile
我正在尝试在 Azure DevOps 中创建发布管道。我们已经有了一个运作良好的构建管道，它能够使用 VSBuild 打包构建并将其发布为工件。然后在发布管道中，我正在使用 IIS 部署作业（包括 IIS 管理和 IIS 部署任务）并获取要部署的工件。
问题是我们已经有一个发布配置文件 (.pubxml)，它应该负责 IIS 部署所做的几乎所有事情（至少据我所知）。所以对我来说，似乎我有两个选项不需要我重构项目配置本身。
- 我可以尝试模仿 IIS 部署作业上的设置以尽可能接近地匹配我们的 .pubxml 并手动应用任何无法通过任务设置进行的更改。显然，这并不理想，因为这将要求我们在进行更改时同时更新两者，并且随着时间的推移，它很可能会导致管道崩溃。
- 我可以放弃使用 IIS 部署的想法，而只使用一个使用参数
/p:DeployOnBuild=true /p:PublishProfile=Staging 的 VSBuild 任务。这似乎不是最佳实践，因为这意味着我的发布管道没有传递要部署的构建包，它只是在每个阶段创建一个新包。
那么有没有更好的选择可以让我在部署中同时使用我用 VSBuild 创建的包和 .pubxml 配置？如果这不可能，那么我的选择是否是处理我的情况的“正确”方式，或者我只是缺少我可以使用的另一种部署方法？
感谢您提供的任何帮助或见解。如果我能提供更多有用的信息，请告诉我。
您可以尝试使用发布设置文件 (*.publishsettings) 进行 IIS 部署。
A publish settings file (.publishsettings) is different than a publishing profile (.pubxml) created in Visual Studio. A publish settings file is created by IIS or Azure App Service, or it can be manually created, and then it can be imported into Visual Studio.
查看更多详情，您可以查看：
所以不幸的是，似乎没有一种方法可以实现我想要的一切。当我们构建项目时需要发布配置文件，因此无需更改我们配置这些配置文件的方式，我就可以在需要部署时构建项目。最终我选择了选项#2。我基本上只是复制了测试管道中使用的大部分构建任务，并将它们放在发布管道中，并使用一些修改过的命令在完成后实际部署构建。这一切似乎工作得很好，但仍然不是最佳实践。如果我遗漏了什么，请告诉我，我会进行适当的更新。
我正在尝试在 Azure DevOps 中创建发布管道。我们已经有了一个运作良好的构建管道，它能够使用 VSBuild 打包构建并将其发布为工件。然后在发布管道中，我正在使用 IIS 部署作业（包括 IIS 管理和 IIS 部署任务）并获取要部署的工件。
问题是我们已经有一个发布配置文件 (.pubxml)，它应该负责 IIS 部署所做的几乎所有事情（至少据我所知）。所以对我来说，似乎我有两个选项不需要我重构项目配置本身。
- 我可以尝试模仿 IIS 部署作业上的设置以尽可能接近地匹配我们的 .pubxml 并手动应用任何无法通过任务设置进行的更改。显然，这并不理想，因为这将要求我们在进行更改时同时更新两者，并且随着时间的推移，它很可能会导致管道崩溃。
- 我可以放弃使用 IIS 部署的想法，而只使用一个使用参数
/p:DeployOnBuild=true /p:PublishProfile=Staging的 VSBuild 任务。这似乎不是最佳实践，因为这意味着我的发布管道没有传递要部署的构建包，它只是在每个阶段创建一个新包。
那么有没有更好的选择可以让我在部署中同时使用我用 VSBuild 创建的包和 .pubxml 配置？如果这不可能，那么我的选择是否是处理我的情况的“正确”方式，或者我只是缺少我可以使用的另一种部署方法？
感谢您提供的任何帮助或见解。如果我能提供更多有用的信息，请告诉我。
您可以尝试使用发布设置文件 (*.publishsettings) 进行 IIS 部署。
A publish settings file (.publishsettings) is different than a publishing profile (.pubxml) created in Visual Studio. A publish settings file is created by IIS or Azure App Service, or it can be manually created, and then it can be imported into Visual Studio.
查看更多详情，您可以查看：
所以不幸的是，似乎没有一种方法可以实现我想要的一切。当我们构建项目时需要发布配置文件，因此无需更改我们配置这些配置文件的方式，我就可以在需要部署时构建项目。最终我选择了选项#2。我基本上只是复制了测试管道中使用的大部分构建任务，并将它们放在发布管道中，并使用一些修改过的命令在完成后实际部署构建。这一切似乎工作得很好，但仍然不是最佳实践。如果我遗漏了什么，请告诉我，我会进行适当的更新。