Подтвердить что ты не робот

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

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