使用配置转换,使用MSI部署的桌面应用程序在VSTS上构建/发布流程

Question

我们正在为客户端部署的桌面应用程序(winforms)实施DevOps策略.到目前为止,我们使用SlowCheetah进行配置转换(例如:从配置管理器中选择QA,自动交换app.QA.config,进行构建,使用SCCM将MSI部署到QA机器).

我们正在尝试利用Azure DevOps来自动执行此过程,但我遇到了障碍.我想做1个版本,以及Dev - > QA - > UA - > Prod的发布管道,但由于配置转换仅在构建上运行,我不知道该怎么做.

MSI只会为当前选定的配置生成,因此释放步骤中的下降只有1个MSI(配置已经打包,无法更改).

我知道构建步骤构建解决方案4次(每个配置一个)将起作用 - drop将包含所有4个MSI,但这看起来很愚蠢.

我不能只在发布管道上构建安装项目,因为Drop中只有DLL可用,而不是项目文件.我怎么能做到这一点？

谢谢!

Answer 1

我们在包含WiX安装程序项目的Visual Studio解决方案中构建MSI时遇到了同样的问题,使用app.config上的配置转换来替换配置.

正如您所建议的那样,我们最初沿着运行Azure DevOps构建管道的路线开始,该管道具有针对解决方案中的每个配置的多个构建,但是这很快变得不优雅和浪费,因为我们不仅需要构建(dev/stage/qa/live) )但也有适用于多个客户的配置,最终解决方案中的12 +配置和很长的构建时间.

替换MSI中的配置

我们最后提到的解决方案是在构建管道中仅构建一次MSI,将MSI以及所有替换的app.config文件复制到drop文件夹,然后运行自定义应用程序在发布管道中强行替换MSI中的Application.exe.config.不幸的是,这不仅仅是'解压缩MSI',更换配置,然后在发布任务中"重新压缩",因为MSI使用自定义文件格式并维护需要正确修改的内部数据库.

我们最终使用此堆栈溢出答案中发布的方法创建了一个自定义C#.NET控制台应用程序,然后我们在我们的本地构建代理上托管这些应用程序,以便我们可以在我们的发布管道中运行一个简单的PowerShell任务,该管道调用我们的自定义控申请与一些相关参数:

"C:\BuildTools\msi_replace_file.exe" -workingfolder "$(System.DefaultWorkingDirectory)/_BuildOutput/drop/Application.Installer/bin/Release/" -msi "Application.Installer.msi" -config "Application.exe.config" 

然后,我们为执行这些基本步骤的每个"配置"创建了一个发布管道阶段:

如本问题所述,还有其他各种方法可以替换MSI中的文件,但我们选择使用Microsoft.Deployment.*命名空间中的实用程序创建一个C#应用程序,这些实用程序是作为WiX工具集的一部分提供的.这将保证与我们用于构建安装程序的WiX版本的兼容性,并使我们完全控制该过程.但是,我很欣赏这种方法非常脆弱(我并不高兴),并且由于依赖于在我们的内部部署构建代理上托管的自定义工具,因此不具备可扩展性.我打算将来改进这个.

您还应该意识到,以这种方式攻击MSI可能会在将来导致问题,尤其是在您更改工具链或升级到更高版本的WiX时.

从发布管道构建MSI

我个人并不喜欢将所需的dll/assets复制到放置位置然后在发布管道中"构建"MSI的想法,因为对我们而言,构建WiX项目的行为是我们"构建过程"的一部分.并且已经集成到我们的可视化工作室解决方案中,所以感觉就像将MSI的创建移动到发布管道一样反直觉,并且还可能要求我们在构建代理上创建自定义任务以运行WiX CLI工具(heat.exe) ,light.exe,candle.exe)针对我们的WXS文件版本,或者具有构建wixproj文件而不是整个解决方案的构建步骤.但是,我可以看到这种替代方法如何适合其他人,我认为根据您的情况同样有效.