Как использовать разные наборы файлов свойств на сервере сборки и на машинах разработчиков? - PullRequest
Новая
       68

Как использовать разные наборы файлов свойств на сервере сборки и на машинах разработчиков?

4 голосов
/ 18 января 2012

У меня есть веб-приложение. Я настраиваю CI для этого.

Мы не использовали инструмент сборки (ни Ant, ни Maven), а создавали сборки с помощью IDE. Сейчас я работаю над сценарием Ant, который будет использоваться нашей системой сборки.

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

Каковы общие подходы к решению такой ситуации?

Если бы мы использовали Maven, я бы, вероятно, использовал разные профили, но у нас есть Ant.

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

/profiles
    /dev1
       prop1.properties
       prop2.properties
    /dev2
       prop1.properties
       prop2.properties
    /build-server
       prop1.properties
       prop2.properties
/webapp
    /WEB-INF

Затем во время сборки Ant мы можем скопировать правильный набор в правильное местоположение. Но может возникнуть проблема при сборке с помощью IDE, как мы привыкли делать (поскольку файлы свойств больше не хранятся в своем правильном месте в папке src).

Есть ли другие подходы?

1 Ответ

5 голосов
/ 18 января 2012

Если я вас понимаю, вы создаете отдельные ear / war / jars для каждой среды на сервере непрерывной сборки. Это правильно?

У меня есть два способа справиться с этим: Smart Way и Dumb Way :

Smart Way

Разумный способ - настроить сервер приложений (JBoss, Weblogic и т. Д.) На поиск необходимого файла свойств, внешнего по отношению к jar / ear / wars, которые установлены на сервере приложений. Таким образом, вы создаете один набор jar / ear / wars, и он работает везде. Кроме того, вы делаете что-то очень, очень важное: вы заставляете Finger O 'Blame указывать в другом месте.

Если файлы свойств упакованы как часть jar / ear / war, и что-то на сервере изменилось, вы получите вину, потому что ваша сборка была плохой. Конечно, у вас не было возможности узнать, что они изменили среду, но вы установили этот неверный файл сборки на рабочий сервер.

Однако, если свойства хранятся за пределами артефакта сборки, то именно команда, ответственная за настройку серверов, виновата.

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

тупой путь

Мы умели делать умный путь 1025 * в моей последней компании. В моей нынешней компании мы делаем вещи Dumb Way . Свойства встроены в наш артефакт сборки, и изменить его несложно.

Я разделил каждый набор файлов свойств по суффиксам, а не по разным каталогам (т.е. build.properties.dev1, build.properties.dev2 и т. Д.). Мы поместили файлы свойств в один каталог.

Когда я делаю сборку, я использую задачу AntContrib <for>, чтобы выполнить цикл сборки несколько раз, каждый раз с другим файлом свойств. Затем я создаю артефакт для каждого набора файлов свойств. Я использую суффикс в файле свойств в качестве имен папок в моем каталоге target, где хранятся встроенные артефакты. Таким образом, каждая сборка создает все артефакты для всей среды.

Таким образом, если артефакт работает в среде dev , он будет работать в QA и Production . Единственная проблема заключается в том, что я храню в 5–10 раз больше артефактов на моем сервере Jenkins, поэтому мне нужно в 5–10 раз больше дискового пространства.

Кстати, пока я могу определить <fileset> для поиска файлов свойств, я могу использовать задачу <for>, чтобы вы могли использовать разные каталоги. И вы можете использовать <basename>, чтобы вытащить имена каталогов.

...