Как обрабатывать код для разных сред - PullRequest
Новая
       8

Как обрабатывать код для разных сред

0 голосов
/ 02 февраля 2020

Я работаю над проектом java (maven), где код в средах разработки и тестирования отличается от производственного. Различные части - это, в основном, файлы конфигурации или файлы, связанные с Docker, но, тем не менее, это создает путаницу. Если бы я сохранил файл pom или Dockerfile prod, dev не работал бы и наоборот.

Прямо сейчас, при развертывании на prod, я создаю новую ветку в git из существующего deploy ветвь, в которой уже есть другой Dockerfile и pom.

Там я извлекаю изменения из каталога src /, например 

$ git checkout origin/feature-name —- src/

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

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

ОБНОВЛЕНИЕ

Фактический код в каталоге src / не меняется. Изменения между средами заключаются в том, что

  • среды разработки / тестирования используют секреты, а prod - нет, то есть разные docker -композитные файлы и разные точки входа
  • POM-файл в работе имеет дополнительные элементы (то есть родитель, указывающий на частный артефакт). Как уже упоминалось @Saeed, использование профилей не может добавлять / изменять или элементы.
  • В рабочем Dockerfile используются личные изображения, недоступные во время разработки (или тестирования). Вместо этого я использую эквивалент c publi.

1 Ответ

0 голосов
/ 02 февраля 2020

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

в соответствии с документацией Maven профиль может настраивать следующие элементы POM 

<repositories>
<pluginRepositories>
<dependencies>
<plugins>
<properties> (not actually available in the main POM, but used behind the scenes)
<modules>
<reporting>
<dependencyManagement>
<distributionManagement>

подмножество элемента <build>, которое состоит из: 

<defaultGoal>
<resources>
<testResources>
<finalName>

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

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

<profile>
    <id>no-tests</id>
    <properties>
        <maven.test.skip>true</maven.test.skip>
    </properties>
</profile>

и при передаче имени профиля в Maven и активировать его с помощью ключа -P, Maven применит настройку, определенную внутри профиля, и в этом примере запустив: 

mvn clean install -P no-tests

, пропустит запущенные тесты

Профили Maven действительно мощные и обрабатывают высокая настройка, если вы можете использовать его хорошо

...