Самый простой способ развертывания на производстве со сборками

Ответ 1

Shabunk, поскольку я был прокомментирован, Maven заставляет вас наилучшим образом делать то, что вы хотите, унаследовав от опыта опыта разработчиков.

Я бы объяснил, что я (и что я на самом деле) делаю.

Итак, вы правы, чтобы использовать Maven Release Plugin, а также еще один (например, груз) Вы пытаетесь сделать две вещи:

• Идентификация уникальной версии, что означает ее пометку и обновление pom для новой версии
• Развертывание вашего приложения (независимо от того, какая среда оно есть)

Плагин релиза Maven

Учтите, что ваш собственный процесс, возможно, более длинный, чем другие команды разработчиков. Я имею в виду, что между модульными тестированиями и производством в больших командах есть больше шагов (Q & A, прием пользователей, нерегрессивные лагеря). Кажется, что вы создаете ярлык, связывающий тег и развертывание производства. Если вы хотите развернуть свой webapp в разных средах (интеграция, пользовательская согласованность, производительность, препрод и т.д.), Вам нужно было идентифицировать вашу версию и иметь возможность ее снова создать (обязательно и "повторяемо" ).

То, для чего предназначен maven-release-плагин. Это поможет вам убедиться, что ваш исходный код чист (все файлы, находящиеся под контролем источника, без изменений), могут собирать и передавать все этапы тестирования. Затем он имеет дело с версией pom и тегами и заканчивается, сохраняя ее для последующего использования в вашем репозитории предприятий Maven.

У вас есть много настроек для настройки (настройка ditributionManagement, SCM, maven plugin). Но как только он будет установлен, выпуская версию стоит в одной простой командной строке:

mvn release:prepare release:perform

Если вам нужны некоторые примеры, я могу дать вам некоторые.

<scm>
    <!-- Base URL repository -->
    <url>scm:svn:http://svn.myorg.corp/svn/repository/</url>
    <!-- Developper URL (from trunk or branche) -->
        <developerConnection>scm:svn:http://svn.myorg.corp/svn/repository/trunk/project1</developerConnection>
  <connection>scm:svn:http://svn.myorg.corp/svn/repository/trunk/project1</connection>


</scm>
<build>
    <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-scm-plugin</artifactId>
                <version>1.6</version>
                <configuration>
            <username>${from.settings.xml.user}</username>
            <password>${from.settings.xml.password}</password>
                </configuration>
    </plugin>

    <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-release-plugin</artifactId>
                <version>2.2.2</version>
                <configuration>
                <tagBase>http://svn.myorg.corp/svn/repository/tags/</tagBase>
            <scmCommentPrefix>[DEV#SCM]</scmCommentPrefix>
        </configuration>
    </plugin>
</plugins>
    [...]
</build>
<distributionManagement>
    <repository>
        <id>enterprise_repo</id>
        <name>Enteprise Repository on Artifactory - Stable versions</name>      <url>http://repo.corp:8080/artifactory/prj-xxx-releases</url>
    </repository>
    <snapshotRepository>
        <id>enterprise_repo</id>
        <name>Enteprise Repository on Artifactory - DEV versions</name>
        <url>http://repo.corp:8080/artifactory/prj-xxx-snapshots</url>
    </snapshotRepository>
    <site>
        <id>corporate_site</id>
        <name>Corporate public site</name>
        <!-- must add wagon plugin that support this protocol -->
        <url>ftp://...</url>

    </site>
</distributionManagement>

Deployement

Еще раз, у вас может быть несколько окружений, на которые вы хотите протестировать свое приложение. Существует много плагинов, которые позволяют отправлять и развертывать вашу войну: общий плагин-плагин, или более конкретные модули tomcat-плагин, плагин для плавающей... Плагины дают вам возможность делать то, что вы хотите. Затем конфигурация может быть выполнена разными способами.

Полный путь Maven: Полностью интегрированный способ с Maven заключается в использовании профиля и, возможно, фильтров. Профили позволяют описывать свойства и поведение, как вы, кажется, знаете. Фильтры являются своеобразными .properties, группирующими набор переменных, которые будут использоваться для замены шаблонов в вашем файле конфигурации xml на войне (например, соединение db). Это не тот, который я использую, потому что я нахожу его менее гибким, чем внешние файлы. Но не важно

Maven с его экосистемой: Я предпочитаю создавать свои приложения с помощью Maven и Jenkins (или инструмента непрерывной интеграции). Вот почему я согласен с Аароном, когда он говорит, что вам нужно ограничить свои инструменты. Используя Jenkins, я запускаю каждый час в день мое приложение против тестов Unit, генератор Q & A отчетов, документации,... У меня есть сборка релиза, которая помогает мне создавать все, что я хочу доставить (моей тестовой команде или моему клиенту), и я предоставляю некоторую информацию моим заданиям, чтобы развернуть ее на разных средах (используя профили maven или встроенную конфигурацию jenkins).

Он отлично работает для меня, и я уверен, что это правильный способ сделать.

[EDIT]

Развертывание

И снова развертывание означает разные фазы жизненного цикла.

Локальная/Dev-окружающая среда

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

Непрерывная интеграция среды В непрерывной среде интеграции я обычно копирую войну непосредственно с Дженкинсом (экспортируя *.war на желаемую машину). То, как я это делаю, зависит от многих вещей:

• если CI soft находится на одном и том же (физическом | виртуальном) сервере, чем ваш сервер приложений (Tomcat, Jboss, Weblogic, Glassfish,...), или отдаленный один = > время копирования выйдет за время обновления сервера и приведет к небезопасным развертывание (обычно поврежденные архивы).
• если сервер поддерживает горячую перезагрузку (взорванную войну в веб-приложениях для Tomcat) или, по крайней мере, знает изменения файловой системы (полная война в/для JBoss)
• если вам нужно остановить сервер раньше,...

В большинстве случаев это простая копия. Если я не могу, я использую некоторые интегрированные плагины maven (например, jahia: развернуть плагин для знаменитой CMS: www.jahia.com) или просто плагин для загрузки: http://cargo.codehaus.org/Maven2+plugin. У меня нет никакого примера, но очень легко найти некоторых в Интернете, потому что эта конфигурация часто рекомендуется.

Q & A/Accept/Production environmentnement

Для тех видов окружающей среды, которые часто (насколько я видел в своей работе) имеет дело с Соглашением об уровне обслуживания, мы (я или команда администратора) писали некоторые конкретные сценарии. Я уверен, что вы будете обескуражены, но, как я упоминал, я не полагаюсь на Maven для всего и для развертывания в частности. ИМХО, это один предел этого инструмента. Возможно, вы можете полагаться на грузовой плагин или на конкретные, но выпускать версию или строить ее не соответствуют (по времени) при реальном развертывании. Более того, я не нашел плагина, который позволяет мне легко развертывать на нескольких экземплярах... и даже стоило вам отключить экземпляры в определенном порядке (потребности SLA). Тем не менее, я не упоминал внешние свойства, SQL-скрипты или что-то еще. Это дополнительные причины полагаться на выделенный инструмент.

Итак, как правило, мы написали собственные скрипты ant/sell. Если у кого-то есть лучшие решения, я, очевидно, заинтригован!

Надеюсь, я был достаточно ясным.

С уважением.

Ответ 2

Первоначальный вопрос требует "наилучшей практики" для развертывания производства с Maven. Я ожидал получить более чем одну "лучшую практику" и предложил щедрость увидеть различные решения и узнать от них. Меня не волнует, являются ли они чистыми решениями maven или используются различные инструменты.

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

В моем текущем проекте у меня есть среда разработки, тестовая среда, промежуточная среда и производственная среда. От моего maven pom я хотел бы работать с средой разработки и развертываться только в тестовой среде. Я вижу следующие подходы с maven pom:

• профили с фильтрующими свойствами
  При работе с таким подходом необходимо восстановить исходный файл (файл войны) для разных сред. Это заставило меня предложить щедрость, потому что мне это не понравилось.
• profile wit Оверлей Maven WAR или сборщик плагинов
  Это также создавало различные артефакты для разных платформ. Но вместо того, чтобы перестроить файл войны, он будет распакован/исправлен/переупакован (для наложения войны) или будет создан и упакован с различными настройками (плагин сборки). Мне тоже не понравилось это решение.
• Плагин развертывания (например, Плагин для загрузки) без профилей
  Укажите полную сборку с инсталляцией, а также включите плагин для работы с порталом, но не подключите его к какой-либо фазе. Поэтому я всегда работаю с средой разработки, но когда я прямо называю грузовой плагин, он развертывает войну из хранилища в контейнер (тестовую среду). Я даже могу использовать профили для различения различных контейнеров только для развертывания через груз.

Во всех решениях я использую интеграционный тест (плагин верфи), плагин версии и плагин выпуска для построения войны. Для развертывания я реализую подход номер 3, следуя аргументам fooobar.com/questions/115650/... (сообщение, которое выражает очень хорошее, что я также предпочитаю).

Поскольку приложение должно работать без изменений во всех средах, вы должны различать разные настройки во время выполнения, и это может быть очень сложно. Наша операционная группа хочет иметь настройки для каждого приложения за пределами контейнера, поэтому я поддерживаю среду var, которая указывает мне на соответствующий каталог, но не является обязательной. Если ничего не задано, я использую настройки разработки в войне. См. Образец Spring здесь:

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="ignoreResourceNotFound" value="true"/>
    <property name="locations">
        <list>
            <value>classpath:META-INF/spring/*.properties</value>
            <value>file:///${picservice.configdir:-}/*.properties</value>
        </list>
    </property>
</bean>

Всегда сохраняются свойства в каталоге META-INF/ spring. Кроме того, я интегрирую свойства из файловой системы, которые могут переопределить указанные выше свойства. Если свойства не обнаружены, это не вызовет исключения, потому что я установил ignoreResourceNotFound. Если свойство picservice.configdir установлено, оно направляет меня к каталогу, если не соответствует значению по умолчанию :. - говорит, что я не хочу иметь значение, которое является текущим каталогом.

Для ведения журнала у меня есть аналогичное решение. Вы можете найти очень интересные статьи об обработке файлов свойств с помощью Spring по следующим ссылкам:

• http://springtips.blogspot.co.at/2008/09/configuring-applications-with-spring.html
• http://www.summa-tech.com/blog/2009/04/20/6-tips-for-managing-property-files-with-spring/
• и аналогичное обсуждение здесь: Использование Maven для множественной среды развертывания (производство/разработка)

Я нашел интересную презентацию по этой теме, см. Автоматическое развертывание с Maven и друзьями.

Ответ 3

обновить git repo, добавить тегирование и обновить версию сборки.

-

Я читал о плагине выпуска, а также о плагине buildnumber. Но я просто не уверен, что иду правильным путем.

Да, рекомендуется использовать плагин release. Вы можете использовать плагин buildnumber, если вы хотите, чтобы номер с номером в каком-либо документе, например. Changes.txt

Ответ 4

Я думаю, что самый простой способ выполнить то, что вы указали (если я хорошо понял), это настроить Maven Release Plugin следующим образом:

<!-- path: project/build/pluginManagement/plugins -->
<plugin>
  <artifactId>maven-release-plugin</artifactId>
  <configuration>
    <releaseProfiles>prod</releaseProfiles>
    <goals>tomcat:deploy</goals> 
  </configuration>
</plugin>

Для развертывания dev выполните следующие действия: mvn tomcat:deploy -P dev (если dev активен по умолчанию, удалите аргумент -P dev).

При отпускании выполните два шага как Maven Release Plugin ожидает:

mvn release:prepare

Эта цель увеличит версию и тег по вашему желанию (и многое другое). Обратите внимание, что вам также необходимо указать, что SCM Maven следует использовать, настроив этот тег в POM:

<!-- path: project -->
<scm>
  <connection>scm:git:ssh://yourrepo.url</connection>
</scm>

Плагин SCM поддерживает широкий спектр менеджеров и протоколов SCM (вас может заинтересовать git:http или git:https).

И затем

mvn release:perform

Это будет использовать профиль prod и просто запустить цель tomcat:deploy, именно то, что вы настроили.

Надеюсь, это то, что вам нужно. С наилучшими пожеланиями.

Ответ 5

Решение Mavenized не должно использовать Maven, если у вас есть исключение из общего дела. Maven - это общий пример. Исключения обрабатываются в другом месте, что означает, что POM (должен) никогда не будет содержать никаких сюрпризов.

Поскольку вам нужен настраиваемый процесс развертывания, напишите оболочку script или Ant build.xml, которая выполняет необходимые действия и использует Maven в процессе для развертывания.

Таким образом, каждый инструмент делает то, что он может сделать лучше всего.

[РЕД.] Примечание для всех нижеперечисленных источников: если у вас нет аргумента, ваш проголосовавший голос ничего не значит. Maven - это инструмент. Как и все инструменты, у него есть ограничения. Основная философия Maven заключается в том, чтобы избежать исключений. Ant - все о угловых случаях, Maven - это основной поток. Из Что такое Maven?":

• Простое создание процесса сборки
• Предоставление единой системы сборки

(мой акцент) Итак, есть вещи, для которых Maven - не лучшее решение. Если стандартный процесс выпуска работает для вас, используйте плагин .

Но когда этого не происходит, тогда посмотрите в другом месте, а не на " все выглядит как гвоздь" ловушка ума".

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

Ответ 6

возможно, phing его другой инструмент для решения вашей проблемы, его простой, и вы можете создавать пользовательские процессы

Веб-сайт Phing