Есть некоторые большие дискуссии и предложения, как бороться с номером 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>
И здесь недостающие звенья:
Я отмечаю это как правильный ответ, потому что видео You Tube было отличным ответом на этот вопрос. Однако мне пришлось несколько раз остановиться и перемотать несколько раз, чтобы получить некоторые более тонкие точки. поставили сводку процесса, рекомендованного в видео, в моем собственном ответе. – ams
Видео довольно хорошее и поможет вам загрузиться. @ 23m35s в видео, я бы сказал, что Maven должен выполнить большую часть краткосрочной проверки здравомыслия, например, модульные тесты, проверки покрытия, интеграционные тесты и т. Д. ... однако непрерывная доставка не прекращается. Для крупных организаций типа SOA разбиение вашего трубопровода на незаметные фазы на самом деле является очень хорошей практикой, например, функциональные тесты с издеваемыми конечными точками, тесты производительности, большие интеграционные тесты, тестирование UAT, проверка соответствия, анализ статического кода, обзор безопасности и т. Д. – user924272
Отличное видео. Моя единственная забота - это то, что люди делают со всеми «кандидатами на выпуск» в репо-релизе, которые официально не выпускаются? У нас есть график очистки для наших SNAPSHOT, однако выпуски артефактов хранятся навсегда. Я вижу это, используя много дискового пространства, на стороне хранилища Maven. – Patrick