В нашем выпуске Windows есть разные наборы файлов конфигурации и двоичных ресурсов для разных клиентов. Прямо сейчас настройка выполняется вручную перед упаковкой и подвержена ошибкам. Что вы думаете об использовании ветвей для каждого клиента и о том, что сборка пакета / скрипт автоматически объединяет ветку клиента с магистралью?
Меня меньше заботит масштабируемость, чем автоматизация как можно скорее.
Все содержимое пакета находится в SVN, но ветвление и слияние SVN настолько деликатно, что я не верю, что он будет работать согласованно, когда он автоматизирован. Если вам нравится идея, я могу попробовать использовать для этого git-svn, потому что, надеюсь, это сделает слияние менее деликатным. Нам не обязательно объединять ресурсы, потому что они организованы таким образом, что установщик может просто пропустить неподходящие деревья каталогов, но настройка не так проста.
Полагаю, это зависит от того, сколько вещей нужно изменить. Что касается файлов конфигурации, мне нравится держать один файл под контролем источника и использовать сценарий сборки для установки элементов, зависящих от среды (или, в вашем случае, от клиента).
http://automaticchainsaw.blogspot.com/2008/02/automate-config-changes-for-different.html
Что касается двоичных файлов, это, вероятно, больше связано с тем, сколько их у вас есть и откуда они берутся. Если они являются частью компиляции кода, то в идеале процесс компиляции создаст то, что вам нужно. Если это другие ресурсы, например графика, возможно, у вас есть индивидуальный набор папок в одном каталоге. Сценарий сборки будет извлекать правильную клиентскую папку на основе параметра, переданного сценарию. Это в основном идея ветки и слияния, которую вы упомянули в своем вопросе.
Что касается вашего более позднего комментария об изменениях многострочной конфигурации - если это xml, вы можете посмотреть класс XmlMassUpdate в Задачах сообщества MSBuild. Сам не использовал, но похоже, что это может быть то, что вам нужно.
Вы не указываете, какой язык, но вы можете подумать о том, чтобы сделать условная компиляция:
#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
Это может произойти для разных клиентов, сред (QA, Staging, Production, ...), регионов (США, ЕС, Азия, ...) или разных типов приложений (если вам нужно настроить сервер, когда он обслуживает мобильный клиент. а не веб-сайт или компьютер).
Обычно люди либо поддерживают файлы конфигурации вручную (как вы упомянули), что подвержено ошибкам и небезопасно. Или «загляните и вытащите» правильные значения в файлы конфигурации и из них, используя сценарий сборки, как упомянул Педро. Этот подход также означает, что для каждого изменения кода, влияющего на конфигурацию, должен также измениться сценарий, что не идеально. Кроме того, отладка и тестирование этих скриптов (на каком бы языке они ни были) обычно трудны, если вообще возможны.
Столкнувшись с вашей конкретной проблемой, мы разработали решение, основанное на центральном сервере конфигурации, предоставляющем конфигурацию клиентам. Сервер поддерживает наследование значений, аудит и управление версиями изменений, создание шаблонов и даже изменения времени выполнения, передаваемые клиенту в режиме реального времени.
Мы очень близки к тому, чтобы выпустить эту услугу как облачное решение для управления конфигурацией. Если вы хотите попробовать, подпишитесь на бета-версию на http://woot.configchief.com
да, это управление бинарными активами именно так, как мы его настроили. для текстовых изменений мне нравится это для небольшого количества изменений однострочных полей, но для многострочных изменений (полное удаление или добавление строк) я думаю, что это начинает становиться действительно сложным, и его все еще нужно отслеживать вручную .. .