мне нравится думать о существовании двух проблемных пространств:

• создание артефактов (в идеале агностика среды, поскольку это означает, что QA может взять хэш артефакта, запустить свои тесты на этом артефакте, и когда придет время развернуть, проверьте ash, и вы знаете, что это было QA'D. Если ваша сборка создает разные артефакты в зависимости от того, для env QA или промежуточного env или производственного env, вам нужно сделать больше работы, чтобы гарантировать, что артефакт будет производство было протестировано QA и поставлено в постановку)

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

Maven предназначен для первого проблемного пространства. "Путь Maven" - это создание артефактов агностической сборки среды и публикация их в хранилище бинарных артефактов. Если вы посмотрите на жизненные циклы Maven, вы увидите, что фазы останавливаются после артефакта deployed в репозиторий Maven (хранилище двоичных артефактов). Короче говоря, Maven видит свою работу как выполненную в этот момент. Дополнительно, этапы жизненного цикла для блока testing и integration-testing оба из которых должны быть возможны с агностическим артефактом среды, но это не полный набор тестирования, который вам требуется... Скорее, чтобы завершить тестирование, вам нужно будет фактически развернуть встроенные артефакты в реальные окружающая среда.

многие люди пытаются захватить Maven, чтобы выйти за рамки своей цели (включая меня). Например, у вас есть cargo-maven-plugin и ship-maven-plugin которые касаются аспектов за пределами конца maven игры (т. е. после того, как артефакт попадает в репозиторий Maven). Из них я лично чувствую, что ship-maven-plugin (который я написал, hency мой предыдущий "я включил") ближе всего использовать "после maven", потому что по умолчанию он предназначен для работы, а не на -SNAPSHOT версия проекта, который вы проверили на диске, а скорее на версии того же проекта, который он вытаскивает из удаленного репозитория, например

mvn ship:ship -DshipVersion=2.5.1

IMO, груз направлен на использование вокруг integration-test этап в жизненный цикл, но опять же, вы можете захватить его для других целей.

если вы производите термоусадочное программное обеспечение, то есть такое, которое пользователь покупает и устанавливает в своей системе, сама программа установки предназначена для настройки приложения для среды конечных пользователей. Хорошо, чтобы сборка Maven производила установщик, потому что фактический установщик (по крайней мере, несколько) агностик среды. Ok это может быть только установщик Microsoft Windows или только установщик Linux, но это не заботится о том, какие пользователи машины он получает установлен на.

теперь дни, однако, мы склонны больше концентрироваться на программном обеспечении как услуге, поэтому мы развертываем программное обеспечение на серверах, которые мы контролируем. Становится все более заманчивым буксировать к "темной стороне Maven" , где профили сборки используются для настройки внутренней конфигурации артефактов сборки (в конце концов, у нас есть только три среды, в которые мы развертываем), и мы двигаемся быстро, поэтому не хотим тратить время на создание приложение подбирает конфигурацию конкретной среды от внешнего до встроенного артефакта (звучит знакомо?). Причина, по которой я называю это темной стороной, заключается в том, что вы действительно боретесь так, как хочет работать maven... Вам всегда интересно, была ли jar в локальном репозитории построена с другим активным профилем, поэтому вам все время приходится делать полные чистые сборки. Когда придет время перейти от QA к постановке или от постановки к производству, вам нужно сделать полную сборку программное обеспечение... И все модульные и интеграционные тесты в конечном итоге запускаются снова (или вы в конечном итоге пропускаете их и, в свою очередь, пропускаете здравомыслие, которое они могут предоставлять на артефактах, которые они строят), поэтому в действительности вы делаете жизнь сложнее и сложнее... Просто ради того, чтобы поместить несколько профилей в maven pom.xml... Только подумайте, если бы вы следовали пути maven, вы бы просто взяли артефакт из хранилища и переместили его по различным средам, немодифицированным, неповрежденным и с MD5, SHA1 (и, надеюсь, GPG) сигнатурами, чтобы доказать, что это тот же артефакт.

Так, вы спрашиваете, как мы кодируем доставку к продукции...

Ну, есть несколько способов решить эту проблему. Все они имеют схожий набор основных принципов, а именно

• держите рецепт для доставки в среду в системе управления версиями

• рецепт должен идеально иметь две части, среды агностик стороны, и окружающей среде определенной части.

вы можете использовать старые добрые скрипты bash или использовать более "современные" инструменты, такие как chef и puppet, которые предназначены для этого второго проблемного пространства.

рекомендации

вы должны использовать правильный инструмент для правильной работы.

если бы это был я, вот что я бы сделал:

• вырезать релизы с выпуском Maven Плагин

• построенные артефакты должны всегда быть агностиком окружающей среды.

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

• выберите сторону в chef vs puppet war (не имеет значения, на какой стороне, и вы можете изменить стороны, если хотите. Если у вас есть и муравей мышление, шеф-повар может подойти вам лучше, если вам нравится магия управления зависимостями, марионетка может подойти вам лучше)

• разработчики должны иметь право голоса в определении сценарии chef / puppet для развертывания, по крайней мере, агностическая часть этих сценариев.

• операции должны определять конкретные детали производственной среды развертывания chef / puppet

• держите все эти сценарии в SCM.

• используйте Jenkins или любой CI, чтобы автоматизировать как можно больше шагов. Плагин promoted builds для Дженкинса-ваш друг.

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