Как я могу управлять информацией о конфигурации производства / тестирования / разработки с помощью Subversion?

Question

Я работаю над комбинированным веб-клиентским приложением, которое имеет филиалы для производства, тестирования и разработки. Я использую svn post commit hooks для развертывания обновлений на производственных и тестовых серверах. Клиентское приложение должно указывать на разные URL в зависимости от производства, тестирования или разработки. Как я могу управлять этим с помощью Subversion? Варианты, о которых я подумал:

Вариант 1
Сохраните файл с деталями, относящимися к филиалам, которые никогда не объединяются между филиалами.

Этот вариант проще с точки зрения управления сборкой, но подвержен ошибкам, так как я должен помнить, чтобы игнорировать это изменение каждый раз, когда выполняется слияние.

Вариант 2
Создавайте производственные, тестовые и разрабатываемые сборки клиента независимо от того, какая ветвь, и полагайтесь на svn-хуки, чтобы получить правильные двоичные файлы.

Как вы справляетесь с этим? Есть идеи получше?

Answer 1

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

+ dev-server
+---jdbc.properties
+---build.properties
+ test-server
+----jdbc.properties
+---build.properties

Конфигурационные файлы не разветвляются с остальной частью приложения (одноуровневая ветка, ветви и т. Д.). У них есть свое собственное место в дереве SVN, и они выводятся в каждую ветвь как внешнее определение Subversion .

Мы делаем это так, потому что в каждой ветке может быть развернуто много серверов (dev, test, build, автоматизация и т. Д.).

Answer 2

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

Примером соглашения является определение пользовательских разделов конфигурации в основных файлах конфигурации (веб-конфигурация, конфигурация приложения и т. Д.). После этого вы можете сохранить файл connection-strings-development.config, connection-strings -gration.config, connection-strings-testing.config, connection-strings-pre-production.config и соединение-строк-производство. Конфиг в вашем первоисточнике (или общей папке). Процесс сборки затем отбросит соответствующий файл конфигурации строки соединения, переименовав его в просто connection-strings.config.

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

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