управление конфигурацией релиза

Question

Наш комплект поставки Windows имеет разные наборы конфигурационных файлов и бинарных ресурсов для разных клиентов. Прямо сейчас настройка выполняется вручную перед упаковкой и подвержена ошибкам. Что вы думаете об использовании веток для каждого клиента и о том, что сборка пакета / скрипт автоматически объединяют ветку клиента с транком?

Меня меньше беспокоит масштабируемость, чем получение этого автоматического как можно скорее.

Все содержимое пакета находится в SVN, но ветвление и слияние SVN настолько деликатно, что я не верю, что он работает последовательно, когда он автоматизирован. Если вам, ребята, нравится идея, я мог бы попытаться использовать для этого git-svn, потому что, надеюсь, слияние станет менее деликатным. Нам не обязательно объединять ресурсы, потому что они организованы так, что установщик может просто пропустить неподходящие деревья каталогов, но настройка не так проста.

Answer 1

Полагаю, это зависит от того, сколько вещей должно измениться. Что касается файлов конфигурации, мне нравится держать один файл под контролем исходного кода и использовать сценарий сборки для установки элементов, специфичных для среды (или в вашем случае для клиента).

http://automaticchainsaw.blogspot.com/2008/02/automate-config-changes-for-different.html

Для двоичных файлов это, вероятно, больше связано с тем, сколько из них у вас есть и откуда они берутся. Если они являются частью компиляции кода, то в идеале процесс компиляции создаст то, что вам нужно. Если это другие ресурсы, такие как графика, возможно, у вас есть определенный для пользователя набор папок в одном каталоге. Сценарий сборки извлекает правильную папку клиента на основе параметра, переданного в сценарий. Это в основном идея ветвления и слияния, о которой вы упоминали в своем вопросе.

Что касается вашего последующего комментария об изменениях многострочной конфигурации - при условии, что это xml, вы можете посмотреть на класс XmlMassUpdate в Задачах сообщества MSBuild. Я сам этим не пользовался, но, похоже, это то, что тебе нужно.

Answer 2

Это может произойти для разных клиентов, сред (QA, Staging, Production, ...), регионов (США, ЕС, Азия, ...) или разных типов приложений (если вам нужно настроить сервер во время его обслуживания). мобильный клиент, а не веб-клиент или настольный компьютер).

Обычно люди либо поддерживают файлы конфигурации вручную (как вы упоминали), что подвержено ошибкам и небезопасно. Или «выглянуть» в правильные значения в файлах конфигурации и из них, используя скрипт сборки, как упоминал Педро. Этот подход также означает, что для каждого изменения кода, которое влияет на конфигурацию, сценарий также должен меняться, что не идеально. Кроме того, отладка и тестирование этих сценариев (на каком бы языке они не находились) обычно затруднительно, если не невозможно.

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

Мы очень близки к тому, чтобы выпустить эту услугу в качестве облачного решения для управления конфигурацией. Если вы хотите попробовать его, подпишитесь на бета-версию на http://woot.configchief.com

Answer 3

Вы не упоминаете, какой язык, но вы можете рассмотреть возможность выполнения условной компиляции :

#If FirstCustomer Then
   ' <code specific to the FirstCustomer version>.
#ElseIf SecondCustomer Then
   ' <code specific to the SecondCustomer version>.
#Else
        ' <code specific to other versions>.
#End If