Каков путь Maven для автоматических версий проекта при непрерывной доставке?

Ответ 1

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

• Вы представляете себе презентацию на CD с Maven
• Slides

Ключевой вынос - это сборка потенциального выпуска, поэтому используйте плагин выпуска Maven и не используйте моментальные снимки.

Ответ 2

Это мое резюме, основанное на видео, которое отвечает Марк О'Коннор.

• Для решения требуется DVCS, например git, и сервер CI, такой как Jenkins.
• Не используйте сборки моментальных снимков в конвейере непрерывной доставки и не используйте плагин release maven.
• Версии для снимков, такие как 1.0-SNAPSHOT, превращаются в реальные версии, такие как 1.0.buildNumber, где buildNumber - номер задания Дженкинса.

Шаги алгоритма:

• Дженкинс клонирует репозиторий git с исходным кодом и говорит, что исходный код имеет версию 1.0-SNAPSHOT
• Jenkins создает ветвь git под названием 1.0.JENKINS-JOB-NUMBER, поэтому версия снимка превращается в реальную версию 1.0.124
• Jenkins вызывает плагин версий maven для изменения номера версии в файлах pom.xml с 1.0-SNAPSHOT до 1.0.JENKINS-JOB-NUMBER
• Дженкинс вызывает mvn install
• Если mvn install является успешным, тогда Дженкинс будет передавать ветвь 1.0.JENKINS-JOB-NUMBER, а реальная версия без моментального снимка создается с соответствующим тегом в git для последующего воспроизведения. Если mvn install терпит неудачу, тогда Дженкинс просто удалит вновь созданную ветку и завершит сборку.

Я очень рекомендую видео, связанное с ответом Марка.

Ответ 3

Есть несколько замечательных дискуссий и предложений о том, как обращаться с номером версии maven и непрерывной доставкой (CD) (я добавлю их после моей части ответа).

Итак, сначала мое мнение о версиях SNAPSHOT. В maven SNAPSHOT показывает, что это в настоящее время разрабатывается до конкретной версии до суффикса SNAPSHOT. Из-за этого такие инструменты, как Nexus или плагин maven-release, имеют специальную обработку для SNAPSHOTS. Для Nexus они хранятся в отдельном репозитории, и ему разрешено обновлять несколько артефактов с той же версией выпуска SNAPSHOT. Таким образом, SNAPSHOT может измениться, если вы не знаете об этом (потому что вы никогда не увеличиваете число в своем помпе). Из-за этого я не рекомендую использовать зависимости SNAPSHOT в проекте, особенно в мире компакт-дисков, так как сборка не является надежной.

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

Другая проблема SNAPSHOT для меня - это то, что на самом деле не является прослеживаемым или воспроизводимым. Когда я вижу версию 0.0.1-SNAPSHOT в производстве, мне нужно сделать некоторые поиски, чтобы узнать, когда она была создана, из какой версии она была создана. Когда я нахожу выпуски этого программного обеспечения в файловой системе, мне нужно посмотреть на pom.properties или файл MANIFEST, чтобы узнать, старый ли это мусор или, может быть, самая последняя версия.

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

<major>.<minor>-SNAPSHOT

но при создании нового выпуска сервер сборки может заменить SNAPSHOT чем-то более уникальным и прослеживаемым.

Например, одно из следующих:

<major>.<minor>-b<buildNumber>
<major>.<minor>-r<scmNumber>

Таким образом, основной и второстепенный номер можно использовать для маркетинговых вопросов или просто показать, что достигнут новый великий рубеж, и его можно изменить вручную, когда захотите. И buildNumber (номер вашего сервера непрерывной интеграции) или scmNumber (Revision SUbversion или GIT) делают каждую версию уникальной и прослеживаемой. При использовании ревизии buildNumber или Subversion версии проекта даже сортируются (не с номерами GIT). С buildNumber или scmNumber также легко увидеть, какие изменения в этой версии.

Другой пример - это управление версиями stackoverflow, которые используют

<year>.<month>.<day>.<buildNumber>

И здесь недостающие ссылки:

• Версии в конвейере
• Непрерывная доставка и Maven

Ответ 4

Начиная с версии Maven 3.2.1 поддерживаемые версии с постоянной доставкой поддерживаются из коробки: https://issues.apache.org/jira/browse/MNG-5576 Вы можете использовать 3 предопределенные переменные в версии:

${changelist}
${revision}
${sha1}

Итак, что вы в основном делаете:

• Задайте свою версию, например. 1.0.0-${revision}. (Вы можете использовать mvn versions:set, чтобы сделать это быстро и правильно в многомодульном проекте.)
• Поместите свойство <revision>SNAPSHOT</revision> для локальной разработки.
• В среде CI запустите mvn clean install -Drevision=${BUILD_NUMBER} или что-то вроде этого или даже mvn clean verify -Drevision=${BUILD_NUMBER}.

Вы можете использовать, например, https://wiki.jenkins-ci.org/display/JENKINS/Version+Number+Plugin, чтобы генерировать интересные номера сборки.

Как только вы узнаете, что сборка стабильная (например, тесты приемочного прохождения), вы можете нажать версию Nexus или другой репозиторий. Любые нестабильные сборки просто переходят в корзину.

Ответ 5

НЕ ДЕЛАЙТЕ ЭТО!

<Major>.<minor>-<build>

укусит вас в заднюю сторону, потому что Maven обрабатывает что-либо после дефиса как LEXICAL. Это означает, что версия 1 будет лексически выше 10.

Это плохо, как если бы вы запрашивали последнюю версию чего-либо в maven, то выигрыш выше.

Решение состоит в том, чтобы использовать десятичную точку вместо дефиса, предшествующего номеру сборки.

ДЕЛАТЬ ЭТО!

<Major>.<minor>.<build>

Хорошо иметь версии SNAPSHOT локально, но, как часть сборки, лучше использовать

mvn versions:set -DnewVersion=${major}.${minor}.${build.number}

Есть способы получить основную/второстепенную версию из pom, например, с помощью справки: оценивать и передавать переменную окружения перед вызовом версий: set. Это грязно, но я действительно почесал голову (и другие в моей команде), чтобы сделать ее проще, и (в то время) Maven был недостаточно зрелым, чтобы справиться с этим. Я считаю, что Maven 2.3.1 может что-то сделать, помогая этому, поэтому эта информация больше не может быть релевантной.

Хорошо, если кучка разработчиков будет выпущена в той же версии major.minor, но всегда хорошо помнить, что незначительные изменения не нарушаются, а основные изменения в версии имеют некоторые нарушения API-интерфейса или устаревание функциональности/поведения.

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

Ответ 6

В качестве отправной точки вы можете взглянуть на Maven: The Complete Reference. Версии проекта.

Затем появляется хорошая статья в стратегии управления версиями.

Ответ 7

В моей работе для веб-приложений мы в настоящее время используем этот шаблон управления версиями:

<jenkins build num>-<git-short-hash>

Пример: 247-262e37b9.

Это хорошо, потому что это дает вам версию, которая всегда уникальна и прослеживается обратно к сборке jenkins и версии git, которая ее создала.

В Maven 3.2.1+ они, наконец, уничтожили предупреждения об использовании ${property} в качестве версии, что упрощает их сборку. Просто измените все ваши пемы на использование <version>${revision}</version> и постройте с помощью -Drevision=whatever. Единственная проблема заключается в том, что в ваших выпущенных версиях версия останется в ${revision} в фактическом файле pom, который может вызвать всевозможные странные проблемы. Чтобы решить эту проблему, я написал простой плагин maven (https://github.com/jeffskj/cd-versions-maven-plugin), который заменяет переменную в файле.