Специфичная для среды сборка против специфических свойств среды загрузки - PullRequest
4 голосов
/ 16 февраля 2011

Один из вариантов построения - это пакетирование свойств среды во время сборки (например, с использованием профилей maven)

Другой вариант - установить -Denv=production в производственной среде и при загрузке загрузить /${env}/config.properties.(например, это позволяет пружина, но это можно сделать вручную)

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

Вопрос: какие-либо другие существенные плюсы / минусы или практически тот же, какой подход будет выбран?

В отношении: Загрузить специфичные для среды свойства для использования с PropertyPlaceholderConfigurer?

Ответы [ 2 ]

6 голосов
/ 16 февраля 2011

По моему мнению, наличие разных выходных данных для каждой среды является существенным недостатком, поскольку это означает, что вам нужно собрать N копий приложения, выполнить те же команды сборки N раз и т. Д. Слишком легко столкнуться с ошибками, когда вы дали версия "dev" для сайта QA и т. д.

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

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

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

1 голос
/ 16 февраля 2011

У меня есть 2 сборки, одна из которых генерирует двоичный файл (файл war, без какой-либо конкретной конфигурации сервера), а другая - генерирует несколько файлов свойств для каждой среды среды.Процесс развертывания берет войну и связанные файлы конфигурации и делает свое волшебство.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...