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

Question

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

Вариант 1
Держите файл с отраслевыми конкретными деталями, которые никогда не сливались между ветвями.

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Файлы конфигурации не разветвленным с остальной частью приложения (одноуровневый ствола, веток и т.д. ...). У них собственное место в svn-дереве, и они втянуты в каждую ветвь как Subversion external definition.

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