java - уроки - структура проекта maven




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

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

В настоящее время мы не увеличиваем наши номера версий для нашего проекта, и все сидит в версии 0.0.1-SNAPSHOT уже более года. Мне интересно, что такое способ Maven для непрерывной доставки веб-приложений. Кажется, слишком сложно поднять номер версии на каждом коммите, и никогда не натыкаться на номер версии, как мы сейчас делаем, также кажется неправильным.

Какова рекомендуемая передовая практика использования этого типа использования Maven?

Проблема на самом деле двукратная:

  • pom.xml номера версии проекта в отдельном файле pom.xml (и их может быть много).
  • Обновление номера версии во всех зависимых компонентах для использования последних друг от друга.


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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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


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

<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-интерфейса или устаревание функциональности / поведения.

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







continuous-delivery