Как постоянно создавать и развертывать ветки функций с Maven?

Моя команда использует ветки функций для реализации новых функций и постоянно развертывает сборки моментальных снимков в удаленном репо для использования нашими пользователями. Таким образом, "развертывание" действительно означает только "распространение в удаленном репозитории Maven". В настоящее время мы используем только непрерывные интеграционные сборки для ведущей ветки, а не ветвей функций по следующей причине: мы используем Maven для создания наших проектов и распространения JavaDoc и источников вместе с JAR.

Мой план состоял в том, чтобы добавить классификатор в каждую ветвь каждой ветки и ожидать, что он будет использоваться при создании и развертывании артефактов, таких как:

Отрасль: мастер
Классификатор: none
Артефакты: foo-${version}.jar, foo-${version}-sources.jar, foo-${version}-javadoc.jar
Отрасль: feature-X
Классификатор: myfeature
Артефакты: foo-${version}-feature.jar, foo-${version}-sources-feature.jar, foo-${version}-javadoc-feature.jar

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

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

Ответ 1

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

Ответ 2

Я бы предложил использовать соответствующую версию, которая представляет ветку, а также версии, например:

1.0.0-SNAPSHOT для мастера

1.0.0-F1-SNAPSHOT для функции F1

и др.

Это также дает индикатор, из которого был выпущен релиз 1.0.0.

Ответ 3

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

[1.8-SNAPSHOT,1.9-SNAPSHOT)

Отличительная часть внутри номера версии обозначает разные инкрементные этапы одной и той же базы кода:

1.8-alpha1-SNAPSHOT
1.8-alpha1-SNAPSHOT
1.8-beta1-SNAPSHOT

Вот почему приведенный выше диапазон версии будет захватывать выше, а Maven будет заказывать их в этом порядке:

1.8-SNAPSHOT
1.8-alpha1-SNAPSHOT
1.8-alpha1-SNAPSHOT
1.8-beta1-SNAPSHOT

Любой артефакт, несущий имя ветки функции в номере версии (1.8-featureA-SNAPSHOT), будет упорядочен новее, чем моментальные снимки без квалификатора. Но ветвь функции - это "другая" база кода, а не более новое представление той же базы кода. Для нашего тестового сценария интеграции это привело к бесполезным ошибкам тестирования. Филиал функции еще не был готов к тестированию с помощью тестов интеграции.

Теперь мы следуем этому правилу: если вам все равно нужно что-то изменить, почему бы не идентификатор артефакта? Мы меняем идентификатор артефакта для ветвей функций, и он отлично работает.

Ответ 4

Вместо изменения координат maven артефакта вы можете использовать maven-branch-extension, чтобы эффективно создать отдельное пространство имен SNAPSHOT для каждой из функций ветки. Цитата со страницы проекта:

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

Расширение получает текущий Gitветвь и разрешает свойство в URL-адресе репозитория, так что артефакты могут быть сохранены и извлечены правильно. Он также управляет кэширование и извлечение артефактов в локальный репозиторий, чтобы артефакты берутся из репозитория веток функций, если они существуют, при работе с ветвью функций.

Красота заключается в том, что внешние пользователи зависимостей SNAPSHOT полностью изолированы от внутренней работы над ветвями тем.