Использование матричного проекта Jenkins для создания нескольких экземпляров приложения со сложными настройками

Question

Мы создаем (и запускаем) наше веб-приложение, используя Jenkins. У каждого из наших клиентов есть выделенный экземпляр приложения со своей конфигурацией (для общения с конкретным сервером БД, сервером отчетов и т. Д.). Я играю по-разному, чтобы установить конфигурацию для каждого из этих экземпляров, основываясь на "клиентской" оси проекта Jenkins. До сих пор я придумал:

1. Использование поля "Evaluated Groovy script" для возврата карты переменных среды на основе значения оси клиента (по сути, гигантский оператор switch)
2. CLI нашего приложения имеет команду для установки значений конфигурации, поэтому шаг сценария может проверить среду и выполнить соответствующие команды настройки конфигурации (опять же, большой длинный переключатель)
3. Использование значения оси клиента в качестве имени файла для копирования предустановленного файла конфигурации из папки, где-то хранятся конфигурации (так что установка клиента на "client_a" будет копировать $CONFIG_DIR/client_a.json в папку конфигурации приложения внутри рабочей области.

Все это звучит нормально для меня, но мне любопытно услышать:

• Является ли предпочтительным сохранение значений конфигурации вне Jenkins (т. Е. Вариант 3), а не выводить их все в самом задании
• Любые другие подходы, которые можно считать лучшей практикой.