Версии Maven с использованием веток git - PullRequest
Новая
       5

Версии Maven с использованием веток git

0 голосов
/ 02 ноября 2018

Этот вопрос предназначен для получения отзывов о предлагаемой системе управления версиями для многомодульного Java-приложения, созданного с использованием Maven.

Мы разработали мульти-баночную систему (микроуслуги) с около 15 модулями / банками. Некоторые из них (5) являются библиотеками, используемыми другими модулями в системе, но не за ее пределами. Все модули хранятся в отдельных репозиториях git.

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

Цель : свести к минимуму работу, связанную с управлением версиями (обновление номеров версий, объединение вручную из-за разной информации о версиях для каждой ветви и т. Д.).

Как : Модули идентифицируются по имени модуля и имени ветки git, а не по имени модуля и версии

Мы создаем наши собственные "файлы версий", сохраненные в виде ресурсов в каждом модуле. Они содержат время сборки, git commit-id, имя ветки, URL сборки и т. Д. Для самого модуля плюс включенные модули. Поэтому после развертывания нам не нужен номер версии Maven.

Примечание : Для библиотечных модулей вне системы мы используем стандартный подход как для внутренних, так и для внешних модулей. То есть. версионирование со строгим номером с использованием системы зависимостей Maven.

Система, которую я рассматриваю, заключается в

  1. всегда используйте номер версии <branch-name>-SNAPSHOT в файлах pom, плюс настройку Maven для постоянной загрузки последней версии SNAPSHOT (не только ежедневно, как это делается по умолчанию - ref. Что такое снимок Maven и почему мы это нужно? ).
  2. Используйте спецификацию (ref. Maven BOM [ведомость материалов] Зависимость ) для определения зависимостей.

Файл pom для модуля в этой системе будет похож на: 

<project>
 ...
 <version>${revision}</version>

  <dependencies>
    <dependency>
            <groupId>mygroup</groupId>
            <artifactId>bom</artifactId>
            <version>${revision}</version>
            <type>pom</type>
            <scope>import</scope>
    </dependency>
  </dependencies>
 <properties>
   <revision>default_version</revision>
 <properties>
</project>

Эта версия указывается при сборке, выполняя mvn, используя: mvn deploy -Drevision=<branch-name>-SNAPSHOT (ref: https://maven.apache.org/maven-ci-friendly.html).

Как показывает pom, у нас (в основном) будет одна версия спецификации на имя ветви, используемое в системе, с именем версии <branch-name>-SNAPSHOT - так же, как и сам модуль. Файл спецификации должен содержать зависимости, использующие явные версии, также для внутренних системных модулей.

Пример потоков:

  • Простая функция ветвь. В ветви измените pom, чтобы ссылка на спецификацию ссылалась на родительскую ветвь - замените ${revision} для ссылки на спецификацию. То есть. вам не нужна отдельная спецификация (пока ...)
  • Простая ветвь функций для внутренней библиотеки. То же, что и в предыдущем случае, но вам, вероятно, следует создать ту же ветвь для модуля, использующего эту библиотеку, и ту же ветвь для спецификации, обеспечивающую связь двух модулей.
  • Системный выпуск. Создайте ветку релиза на всех модулях (репозитории git). Включая модуль спецификации. Например: release201810. В файле спецификации в ветви release201810 убедитесь, что все упомянутые внутренние системные модули ссылаются на версию release201810-SNAPSHOT.
  • Разработка Parallell. Создайте пользовательскую ветвь для модулей по мере необходимости. Обновите пользовательскую спецификацию, поскольку модули разветвлены для этой разработки.

Это хорошая идея?

1 Ответ

0 голосов
/ 02 ноября 2018

У меня есть некоторые проблемы:

  1. Вы обычно помещаете весь многомодульный проект в один репозиторий git. Затем вы переходите на весь проект, а не на отдельные модули.
  2. Весь проект обычно имеет номер версии в форме x.y.z-SNAPSHOT, который увеличивается с течением времени. Релизы должны быть построены с релизными версиями, в то время как во время разработки вы можете иметь версии SNAPSHOT.
  3. Возможно создать ветки как x.y.z-branchname-SNAPSHOT, но удаление номера версии все вместе очень нестандартно.

Я должен сказать, что каждый раз, когда я отклонялся от стандарта (по уважительным причинам, как устаревшие структуры в компании), это вызывало проблемы позже.

...