Поток сборки / выпуска в VSTS с развернутым настольным приложением MSI с использованием преобразований конфигурации

Question

Мы находимся в процессе реализации стратегии DevOps для нашего развернутого клиентского настольного приложения (winforms). До сих пор мы использовали SlowCheetah для выполнения преобразований конфигурации (например: выберите QA из диспетчера конфигураций, автоматически добавляется app.QA.config, выполните сборку, разверните MSI на компьютерах QA с SCCM).

Мы пытаемся использовать DevOps Azure для автоматизации этого процесса, и я столкнулся с препятствием. Я хочу сделать 1 сборку и конвейер выпуска Dev -> QA -> UA -> Prod, но поскольку преобразование config запускается только на сборке, я не уверен, как это сделать.

MSI будет генерироваться только для текущей выбранной конфигурации, поэтому при удалении на этапе выпуска будет только 1 MSI (с уже упакованной конфигурацией и без возможности ее изменить).

Я знаю, что шаг сборки собрал бы решение 4 раза (по одному на каждую конфигурацию), сработало бы - падение содержало бы все 4 MSI, но это кажется глупым.

Я не могу просто построить проект установки на конвейере выпуска, поскольку в Drop доступны только библиотеки DLL, а не файлы проекта. Как мне это сделать?

Спасибо!

Answer 1

У нас была точно такая же проблема при создании MSI из решения Visual Studio, содержащего проект установщика WiX, с использованием преобразований config в app.config для замены конфигурации.

Как вы и предполагали, мы изначально пошли по пути запуска конвейера сборки DevOps Azure с несколькими сборками для каждой конфигурации в решении, но это быстро стало неэффективным и расточительным, поскольку не только нам требовались сборки для (dev / stage /) qa / live), но также имелись конфигурации, которые применялись к нескольким заказчикам, что привело к 12 + конфигурациям в решении и очень длительному времени сборки.

Заменить конфигурацию в MSI

Решение, на котором мы остановились, как упоминалось в предыдущем ответе, состояло в том, чтобы собрать MSI только один раз в конвейере сборки, скопировать MSI вместе со всеми нашими файлами замены app.config в папку удаления и затем запустить пользовательское приложение в конвейерах выпуска для принудительной замены Application.exe.config внутри MSI. К сожалению, это не так просто, как «разархивировать 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, как описано в этом вопросе , но мы решили создать приложение C # с использованием служебных программ в предоставленном пространстве имен Microsoft.Deployment. *. как часть WiX Toolset . Это гарантировало бы совместимость с версией WiX, которую мы использовали для создания нашего установщика, и давало нам полный контроль над процессом. Тем не менее, я ценю, что этот подход довольно хрупок (что меня не устраивает) и не особенно масштабируем, так как он основан на пользовательском инструменте, который будет размещен на нашем локальном агенте сборки. Я намерен улучшить это в будущем.

Вы также должны знать, что взлом MSI таким способом может вызвать проблемы в будущем, особенно если вы измените свою цепочку инструментов или обновите до более поздней версии WiX.

Сборка MSI из конвейера выпуска

Мне лично не нравится идея скопировать необходимые библиотеки / ресурсы в место отбрасывания, а затем «построить» MSI в конвейере выпуска, потому что для нас сам процесс создания проекта WiX был очень большой частью нашего ». Процесс сборки »и был интегрирован в наше решение Visual Studio, поэтому казалось, что перенос создания MSI в конвейеры релизов противоречит интуитивному принципу и потенциально потребует от нас создания пользовательских задач на агентах сборки для запуска инструментов WiX CLI ( heat.exe, light.exe, candle.exe) в сравнении с версией нашего файла WXS или имеют этапы сборки, на которых просто создается файл wixproj вместо всего решения. Тем не менее, я вижу, как этот альтернативный подход может быть подходящим для других, и я думаю, что он одинаково актуален в зависимости от ваших обстоятельств

Answer 2

То, что мы сделали несколько лет назад, - это поддержка подпапки, содержащей все файлы конфигурации среды При использовании настраиваемого действия во время установки и предоставления этой конкретной среды в командной строке настраиваемое действие извлекает файл конфигурации из папки соответствия среды в configFils.zip.

Структура папок похожа на эту в файле ConfigFiles.zip.

/Dev1/app.config
/Dev2/app.config
/Prod/app.config

MsiExec.exe /i YourMSI.msi /TargetDir=C:\Yourfolder /Config=Prod  

Пользовательское действие извлечет и поместит app.config из папки Prod.

Answer 3

Чтобы сделать это в конвейере выпуска, у вас есть только пара вариантов:

1. Разбейте MSI на части и повторно импортируйте правильную конфигурацию и переупаковку (не знаю, насколько это легко, поскольку я не знаю MSI, но применил этот подход с другими эффективными пакетами .zip)

2. Сборка пакета в конвейере выпуска. Вы говорите, что файлы недоступны в выпадающем списке, но вы управляете этим из своего конвейера сборки (при условии, что это было сделано и с конвейерами Azure). Поэтому вы можете либо изменить свой конвейер, чтобы скопировать необходимые файлы (с заданием копирования) в место, где вы создаете свой дроп, из которого обычно $(build.artifactstagingdirectory). В качестве альтернативы, если вы не хотите смешивать эти файлы в своем отбрасывании, вы можете создать второе отбрасывание артефакта (для этого просто вставьте другое задание публикации артефакта). Если бы я пошел по этому пути, я бы скопировал файлы, находящиеся сегодня в $(build.artifactstagingdirectory), в $(build.artifactstagingdirectory)/packagefiles, а файлы проекта, необходимые для упаковки MSI, в $(build.artifactstagingdirectory)/projectfiles и укажите две задачи публикации артефактов в один из этих каталогов.

Как только у вас появятся дропы, включая файлы для сборки MSI, вам понадобятся задачи для замены в нужном конфиге, а затем задача упаковки MSI, и все будет готово.