Лучшая практика Maven для генерации артефактов для нескольких сред [prod, test, dev] с ​​поддержкой CI/Hudson?

Question

У меня есть проект, который необходимо развернуть в нескольких средах (prod, test, dev). Основные отличия в основном состоят в свойствах конфигурации/файлах.

Моя идея состояла в том, чтобы использовать профили и наложения для копирования/настройки специализированного вывода. Но я застрял, если мне нужно создать несколько артефактов со специализированными классификаторами (например: «my-app-1.0-prod.zip/jar», «my-app-1.0-dev.zip/jar»), или мне нужно создавать несколько проектов, один проект для каждой среды?!
Должен ли я использовать maven-assembly-plugin для создания нескольких артефактов для каждой среды? Во всяком случае, мне нужно, чтобы произвести все их сразу, так что швы, что профили не подходит ... все еще озадачен :(

Любые намеки/примеры/ссылки будут более чем приветствуется.

As я также задаюсь вопросом, как добиться этого в CI Hudson/Bamboo для создания и развертывания этих сгенерированных артефактов для всех сред, на их соответствующие серверы (например: с помощью SCP Hudson плагина)?

Answer 1

Я бы используйте элемент version (например, 1.0-SNAPSHOT, 1.0-UAT, 1.0-PROD) и, таким образом, теги/ветви на уровне VCS в сочетании с профилями (для сред, специфичных для таких машин, как имена машин, имя пользователя passw орды и т. д.), чтобы построить различные артефакты.

Answer 2

Я предпочитаю упаковывать конфигурационные файлы отдельно от приложения. Это позволяет вам запускать ТОЧНОЕ приложение и поставлять конфигурацию во время выполнения. Он также позволяет создавать файлы конфигурации после факта для среды, которую вы не знали, что вам нужно во время сборки. например CERT Я использую инструмент «сборка», чтобы закрепить файлы конфигурации каждого домена в именованные файлы.

Answer 3

Для этого мы используем профили, но у нас есть профиль по умолчанию, который мы называем профилем разработки, и на нем есть файлы конфигурации, и у нас есть профиль «выпуска», в котором мы не включаем (чтобы они могли быть правильно настроены при установке приложения).

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

PS: Еще одна причина, по которой у нас есть только профили разработчиков/релизов, заключается в том, что всякий раз, когда мы отправляем что-то для UAT или PROD, оно было выпущено, поэтому, если есть ошибка, мы можем отслеживать, какое состояние кода было когда приложение было выпущено - легче вставить его в SVN, чем пытаться найти его состояние из истории фиксации.

Answer 4

У меня был этот точный сценарий прошлым летом.

В итоге я использовал профили для каждой более высокой среды с классификаторами. По умолчанию профиль был «не вредит». У меня были профиль DEV, INT, UAT, QA и PROD.

В результате я определил несколько заданий в Хадсоне для создания специфических для региона артефактов.

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

Фактически, когда я настраивал задания, задания QA и PROD всегда настраивались для создания тега. Очевидно, что это то, что вы бы приспособили к своим конкретным правилам рабочего места при развертывании.

Answer 5

Мы реализовали м2 плагин для создания окончательных .properties используя следующий подход:

• Распространенное, окружающей среды, не поддерживающей настройки считываются из common.properties.
• Специфичные, ориентированные на среду параметры считываются из dev.properties, test.properties или production.properties, поэтому при необходимости переопределяют значения по умолчанию.
• Окончательные файлы .properties записываются на диск с экземпляром Properties после чтения файлов в указанном порядке.
• Такой файл .properties - это то, что входит в комплект в зависимости от целевой среды.

Answer 6

Попробуйте использовать https://github.com/khmarbaise/multienv-maven-plugin для создания одной главной WAR и одной конфигурации JAR для каждой среды.