我想配置我们的管道以允许一个构建用于多个环境,而不必创建单独的构建。根据{{3}}的说法,它似乎是有可能的:
- 您可以使用此技术创建默认程序包并将其部署到多个阶段。
我将舞台命名为我的环境(预览),并为该环境创建了一个web.config文件(web.preview.config)。我所有的环境配置文件都与Web.Config文件位于同一路径。
日志显示转换已完成:
2018-11-17T00:26:52.0383966Z [命令] D:\ a_tasks \ AzureRmWebAppDeployment_497d490f-eea7-4f2b-ab94-48d9c1acdcb1 \ 3.4.13 \ ctt \ ctt.exe s:D:\ a_temp \ temp_web_package_06958915987488234 \ D_C \ a \ 1 \ s \ Microsoft.Xbox.Mvp \ Microsoft.Xbox.Mvp.Api \ obj \ Preview \ Package \ PackageTmp \ bin \ Web.config t:D:\ a_temp \ temp_web_package_06958915987488234 \ Content \ D_C \ a \ 1 \ s \ Microsoft.Xbox.Mvp \ Microsoft.Xbox.Mvp.Api \ obj \ Preview \ Package \ PackageTmp \ bin \ Web.Release.config d:D:\ a_temp \ temp_web_package_06958915987488234 \ Content \ D_C \ a \ 1 \ s \ Microsoft.Xbox.Mvp \ Microsoft.Xbox.Mvp.Api \ obj \ Preview \ Package \ PackageTmp \ bin \ Web.config pw i 2018-11-17T00:26:52.4335280Z [command] D:\ a_tasks \ AzureRmWebAppAppDeployment_497d490f-eea7-4f2b-ab94-48d9c1acdcb1 \ 3.4.13 \ ctt \ ctt.exe s:D:\ a_temp \ temp_web_package_06958915987488234 \ Content a \ 1 \ s \ Microsoft.Xbox.Mvp \ Microsoft.Xbox.Mvp.Api \ obj \ Preview \ Package \ PackageTmp \ bin \ Web.config t:D:\ a_temp \ temp_web_package_06958915987488234 \ Content \ D_C \ a \ 1 \ s \ Microsoft.Xbox.Mvp \ Microsoft.Xbox.Mvp.Api \ obj \ Preview \ Package \ PackageTmp \ bin \ Web.Preview.config d:D:\ a_temp \ temp_web_package_06958915987488234 \ Content \ D_C \ a \ 1 \ s \ Microsoft.Xbox.Mvp \ Microsoft.Xbox.Mvp.Api \ obj \ Preview \ Package \ PackageTmp \ bin \ Web.config pw i 2018-11-17T00:26:52.5443873Z XML转换成功应用
我可以看到它首先转换为发行版,然后按照文档中的说明应用了预览(发行版然后是环境)。但是,尽管上面说XML转换成功应用,但是当我检查配置变量时,它们并没有改变。进行转换工作的唯一方法是在排队新的构建时定义buildConfiguration变量,这使我无法在不同的环境中使用相同的构建。
在研究时,我是从docs处找到的:
Web.config是在构建过程中转换的,如果您从“构建”生成部署程序包,然后在“发行”中部署它,则无法在部署之前对其进行转换。
但是医生说我可以在多个阶段使用一个默认软件包...是否仍然意味着我必须为每个环境创建单独的版本? XML转换不是我要解决的方案应该看的东西吗?
提前谢谢!
++编辑:
发布设置: link
发布步骤(我想?我强烈感觉这就是您想要的...): ReleaseSettings
答案 0 :(得分:4)
1)确保进行转换。测试一下 here.
2)确保在VS项目中包含转换文件Web.Preview.config,并复制到输出目录。
3)在构建过程中禁用配置转换,您只需要在构建任务的MSBuild Arguments部分中添加参数/ p:TransformWebConfigEnabled = False即可。如果要在发行期间更新连接字符串,还需要添加/ p:AutoParameterizationWebConfigConnectionStrings = False。这将使用Web.Preview.config来“转换” web.config。
4)仔细检查发布的“文件转换和变量替换选项”下的IIS Web App Deploy任务是否检查了XML转换。
答案 1 :(得分:3)
我在互联网上找不到的答案都对我自己的构建和发布渠道有效。我从发布渠道获得的web.config
始终指向未转换的值。
经过几个小时的梳理,我还是可以工作了。
我希望能够仅通过一个构建和一个发布管道就可以在所有环境中进行部署。
我的设置:
我们的测试阶段在我们的测试服务器上发布了测试分支。 Stage / Production来自相同的发行分支,但是具有自己的转换文件。
我遵循了一些guide from Microsoft,并设置了web.<environment_name>.config
以匹配发布阶段的名称。
对于每次变换,我都不需要从<Dependent Upon>
中删除.csproj
行。相反,我所做的只是将每个转换的属性 Build Action 设置为 Content ,如下图所示。
然后我将这些命令添加到构建管道的Build Solution-> MSBuild Arguments:
/p:MarkWebConfigAssistFilesAsExclude=false
/p:TransformWebConfigEnabled=false
/p:AutoParameterizationWebConfigConnectionStrings=False
该构建现在不会尝试自行转换.config
,也不会从工件中排除转换文件,而是允许发布管道进行转换。另外,保持转换文件的<Dependent On>
可以使我们在代码编辑器中看起来更“干净”。
答案 2 :(得分:0)
我刚刚完成了这项工作,因此我可以构建一个可以部署到多个环境的版本。这就是我所做的。
在代码中,我将每个Web..config属性设置为Build Action =“ Content”。我还将所有矿山都设置为“复制到输出目录” =“始终复制”。我还卸载了该项目并编辑csproj文件,然后删除了Web.config行。这会将您所有的web.configs转储到根目录(无文件嵌套)。
在构建中,我设置管道变量BuildConfiguration =“ Release”。我的项目中没有Web.Release.config。
在发行版中,我以环境命名了部署阶段(在我的情况下是开发,登台和生产)。在所有阶段中,关于Azure部署任务,我都选中了XML Transformation复选框。
在Azure中,我将ASPNETCORE_ENVIRONMENT设置为暂存环境的名称(在我的情况下为开发,暂存和生产)。
答案 3 :(得分:-1)
我也可以正常工作。我的问题实际上是在Visual Studio解决方案级别。我让MVC项目指向与其他项目不同的Configuration。因此,请务必仔细检查配置!