Environments-maven-plugin предоставляет все перечисленные выше вещи.
Environments-maven-plugin является вилкой multienv-maven-plugin . Основная философия multienv-maven-plugin заключается в том, что каждый каталог в каталоге src / main / environment является средой, и для каждого каталога будет создаваться война. Эта философия слишком ограничительна. Это обеспечивает простоту за счет функциональности. Плагин окружений maven продолжает использовать каталоги в src / main / средах в качестве имен различных сред. Но это расширяет плагин дальше. Ниже перечислены некоторые из этих деталей.
Исключение сред.
В большинстве проектов есть файлы ресурсов как для различных сред, так и для запуска кода на компьютере разработчика, но указывающие на различные среды. Например: dev, dev_local, ci, ci_local, qa, qa_local и др. c. - эти файлы ресурсов QA используются для запуска приложения в среде QA. Файлы ресурсов qa_local используются для запуска приложения на компьютере разработчика, указывая на среду QA. Когда запускается сборка релиза, файлы war для dev_local, ci_local и qa_local генерироваться не должны. В противном случае он замедляет сборку и загромождает бамбуковые страницы сборки, что может вызвать путаницу у стороны, выполняющей фактическое развертывание.
environment-maven-plugin позволяет исключить среды, для которых генерация военных файлов нежелательна. Это можно сделать с помощью тега excludeEnvironments в конфигурации плагина.
Пример конфигурации
<plugin>
<groupId>net.sf.environments-maven-plugin</groupId>
<artifactId>environments-maven-plugin</artifactId>
<version>1.1.0-SNAPSHOT</version>
<configuration>
<excludeEnvironments>dev01, qa01 ,qa02,</excludeEnvironments>
<parallel>true</parallel>
</configuration>
<executions>
<execution>
<goals>
<goal>configuration</goal>
</goals>
</execution>
</executions>
</plugin>
Не разрешать настройку манифеста
Когда война файлы генерируются для разных сред, могут быть случаи, когда необходимо добавить специфичные для среды записи c манифеста. Это можно легко сделать с помощью подключаемого модуля Environment-Maven с помощью тега environmentArchiveConfiguration в конфигурации модуля.
Вы можете иметь одну конфигурацию для всех сред или конфигурацию для каждой отдельной среды, как показано ниже.
Для удобства среда уже добавлена в каждый файл войны. Запись манифеста выглядит следующим образом.
<plugin>
<groupId>net.sf.environments-maven-plugin</groupId>
<artifactId>environments-maven-plugin</artifactId>
<version>1.1.0-SNAPSHOT</version>
<configuration>
<excludeEnvironments>dev01, qa01</excludeEnvironments>
<parallel>true</parallel>
<archives>
<environmentArchiveConfiguration>
<environment>dev02</environment>
<archive>
<manifestEntries>
<mode>development</mode>
<key>value</key>
</manifestEntries>
</archive>
</environmentArchiveConfiguration>
<environmentArchiveConfiguration>
<environment>prod01, prod02</environment>
<archive>
<manifestEntries>
<mode>development1</mode>
<key>value1</key>
</manifestEntries>
</archive>
</environmentArchiveConfiguration>
</archives>
</configuration>
<executions>
<execution>
<goals>
<goal>configuration</goal>
</goals>
</execution>
</executions>
</plugin>
Environment-Specifi c Фильтрация
environment-maven-plugin представляет теги commonDir и filters. Тег commonDir принимает путь к каталогу внутри src/main/environnments. Общий каталог содержит шаблоны, которые являются общими для всех сред. Эти шаблоны могут иметь переменные, заключенные в @ (@variable@).
Тег фильтра может иметь несколько тегов фильтра. Каждый тег фильтра принимает имя файла.
Когда создаются войны, плагин выполняет следующие действия.
- Извлекает файлы шаблонов из общего каталога.
- Извлекает файлы с именами, объявленными в тегах фильтра, из каталога среды. Например, если в данный момент создается dev war, плагин пытается найти файлы по тегам фильтра в каталоге src / main / сред / dev.
- Объединяет все пары ключ-значение из всех файлов в тегах фильтра в HashMap.
- Использует эти пары ключ-значение из HashMap для замены переменных в шаблоне.
- Пакетирует файлы из предыдущего шага в файле dev war.
- Также упаковывает все файлы из каталога src / main / environment / $ {env}.
Пример конфигурации
<plugin>
<groupId>net.sf.environments-maven-plugin</groupId>
<artifactId>environments-maven-plugin</artifactId>
<version>1.3.0-SNAPSHOT</version>
<configuration>
<commonDir>common</commonDir>
<filters>
<filter>ec.properties</filter>
</filters>
</configuration>
<executions>
<execution>
<goals>
<goal>environment</goal>
</goals>
</execution>
</executions>
</plugin>
На рисунке ниже показано наименование / структура файла / каталога.
ПРИМЕЧАНИЕ: Чтобы фильтрация работала, должны быть объявлены теги commonDir и filters.
Возможность размещения файлов ресурсов в каталоге Specifi c внутри файла войны
Файлы ресурсов обычно находятся в каталоге WEB-INF / classes внутри файла war. Чтобы добиться этого в multimaven-maven-plugin, нужно создать каталог WEB-INF / classes в каждой из сред внутри src / main / сред, а затем поместить в них файлы ресурсов. Как показано ниже, это избыточно и безобразно.
- src
- main
- окружений
- dev
- dev_local
- ci
- ci_local
Чтобы решить эту проблему, environment-maven-plugin вводит новый тег с именем targetPath . Если этот тег объявлен с путем к каталогу для значения, файлы ресурсов, упакованные в war, помещаются в каталог. Так. это выглядит так.
- app_dev.jar
- app_dev_local.jar
- app_ci.jar
- app_ci_local.jar
Таким образом, структура каталогов в этом случае выглядит следующим образом.
- src
- main
- окружения
- dev
- dev_local
- ci
- ci_local
Пример конфигурации
<plugin>
<groupId>net.sf.environments-maven-plugin</groupId>
<artifactId>environments-maven-plugin</artifactId>
<version>1.1.0-SNAPSHOT</version>
<configuration>
<targetPath>WEB-INF/classes</targetPath>
</configuration>
<executions>
<execution>
<goals>
<goal>environment</goal>
</goals>
</execution>
</executions>
</plugin>
Создание единого Enviro nment
multienv-maven-plugin не позволяет создавать единую среду. В результате необходимо поддерживать совершенно отдельную настройку только для отдельных сред. environment-maven-plugin решает эту проблему с помощью параметра командной строки -Dem.env. Значением параметра является имя каталога интересующей среды в src/main/environment.
mvn clean install -Dem.env=dev_local
Ресурсы
Страница проекта : https://sourceforge.net/projects/environments-maven-plugin/
Исходный код : https://sourceforge.net/p/environments-maven-plugin/code/ci/master/tree/
Обзорная страница : https://environments-maven-plugin.sourceforge.io/index.html
Редактировать
Это то, что https://12factor.net/config говорит о конфигурации.
Apps sometimes store config as constants in the code. This is a violation of twelve-factor, which requires strict separation of config from code. Config varies substantially across deploys, code does not.
environment-maven-plugin позволяет отделить конфигурацию от кода.
Another aspect of config management is grouping. Sometimes apps batch config into named groups (often called “environments”) named after specific deploys, such as the development, test, and production environments in Rails. This method does not scale cleanly: as more deploys of the app are created, new environment names are necessary, such as staging or qa. As the project grows further, developers may add their own special environments like joes-staging, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle.
Обратите внимание, что он предполагает, что ведение отдельных файлов свойств для разных сред хрупко, но не предлагает никаких альтернатив. В то время как кто-то более осведомленный может спорить о достоинствах и недостатках такой идеи, в реальности файлы свойств группируются в различные среды. И когда это так, необходимо правильно упаковать эти группы в военные файлы или напрямую доставить эти группы в соответствующие среды и надеяться, что у человека, занимающегося развертыванием, нет невежества, чтобы умолять и играть политическую роль. environment-maven-plugin использует метод упаковки файлов ресурсов в войны и генерации нескольких войн. После начала войны сервер CI может взять на себя ответственность за развертывание. Не нужно беспокоиться о размещении файлов в нужном месте на сервере или создании переменных среды. Если есть каноническое решение этой проблемы, было бы неплохо знать.
Также обратите внимание, что в нем ничего не говорится о создании нескольких войн.
Обратите внимание, что не было никакого канонического способа, предписанного для признания недействительным предложенного решения.
1.) Не следует хранить пароли в текстовых файлах. Принятая практика - хранить их в переменных среды на серверах. Но, может быть, есть более безопасные способы.
2.) Построение нескольких войн не более ненадежно, чем построение одной войны с использованием тех же версий java и maven. Когда мы используем конкретную версию java и maven, невысказанное предположение состоит в том, что при наличии фрагмента кода несколько итераций сборки приведут к одной и той же войне.
3.) Нельзя полагаться на войну, развернутую на производство, как на единственный источник правды. Это единственная точка отказа. Вместо этого, использование веток релиза для управления выпущенным кодом гарантирует, что у вас будет война, которая может быть последовательно обновлена. Это избавит вас от проблем, если файл war будет поврежден, случайно удален и т. Д. c ..
4.) Обычная практика для воспроизведения производственных дефектов - запуск ветки выпуска на локальном компьютере. Не получить копию развернутой на производстве войны.
5.) Пространство может быть проблемой, если вы сохраняете эти файлы бесконечно.
6.) Построить все войны с помощью этого плагина определенно медленно. Но это должно быть в своем собственном maven профиле. Этот профиль должен быть выполнен на сервере CI. Нужно только создать файл war для одной среды на локальной машине. Плагин позволяет это.
Если Tn = время, затрачиваемое на создание n войн, намного меньше, чем T1 = время, затрачиваемое на построение одной войны, то с этим плагином (Tn) будет немного меньше, чем (n * T1)
7.) Если человек не работает в чьем-то гараже или подвале, маловероятно, что ему разрешат что-либо изменить в производстве в мире java. Но если вы думаете, что вам нравится гибкость изменения файлов конфигурации по желанию в процессе производства, этот плагин не позволяет этого. Просто знайте, что это вводит произвол. т. е. нет никакой гарантии, что текстовые файлы, отправленные вами в производство, являются теми же текстовыми файлами, которые в настоящее время находятся в производстве.
Итак, в заключение, учитывая, что не было явного признания недействительным или даже подрыва подхода, использованного в прошлом. через три месяца можно предположить, что создание нескольких войн так же приемлемо, как и отправка файлов конфигурации отдельно. Это зависит только от того, что вы предпочитаете, будь то религиозная приверженность принятой практике или более простой подход, который устраняет необходимость в посредниках в форме поддержки или иным образом.