Что такое snapshot maven
Maven и управление релизами
Contents
Про релизы и SNAPSHOT-ы
Maven позволяет управлять циклом разработки и сборки проекта. С помощью maven эти процессы стандартизируются для всех проектов.
Конфигурирование pom-файла
Все конфигурации выполняются в pom-файле родительского проекта.
1. Добавить путь к SCM (source control management, например SVN или GIT)
2. Добавить пути к nexus-репозиторию, куда будут паблишиться релизы
3. Указать версию maven-release-plugin. У меня по умолчанию бралась 2.0, в которой был баг.
Maven и управление релизами
Создание релиза состоит из двух стадий:
1. У нас есть многомодульный проект, версия на данный момент 1.0-SNAPSHOT
2. Мы комитаем весь исходный код и вызываем
3. Maven переименовывает все версии на 1.0, делает сборку проекта, запускаетunit-тесты
5. Далее maven инкрементирует версии (в проекте и подпроектах) на 1.1-SNAPSHOT и комитает изменённые pom.xml файлы
После подготовки релиза, в проекте появляются файлы бэкапов pom.xml и файл release.properties. Release plugin использует эти файлы для выполнения релиза.
7. maven достаёт по тегу последний релиз (в нашем случае был 1.0), выполняет сборку и паблишит артефакты на nexus
После этого чистятся все бэкапы pom-файлов и файл release.properties
Подходы к работе с reusable-компонентом
Повторно-используемые компоненты позволяют шарить общий код между проектами, тем самым ускоряя разработку. Для работы с такими компонентами мы используем maven + nexus (internal maven-репозиторий).
Как подключить готовый компонент к проекту
1. В файле maven/conf/settings.xml настроить использование внутреннего nexus-репозитория
2. Подключить компонент как maven-зависимость
Как создать компонент для повторного использования в других проектах
2. Добавить к проекту конфигурацию для работы с релизами (см. раздел «Конфигурирование pom-файла»)
3. Выполнить релиз, после этого проект будет задеплоен на nexus и доступен для использования в других проектах (см. раздел «Maven и управление релизами»)
Что делать, если нужно изменить компонент (добавить код, исправить баг. )
1. Чекаутаем компонент из репозитория
3. Выполняем релиз компонента (см. раздел «Maven и управление релизами»), убеждаемся что зарелизанная версия отличается от предыдущей (к примеру, до модификации была версия 1.2-SNAPSHOT, значит старая версия проекта будет 1.1, версия, которая пойдёт в релиз будет 1.2)
4. Проекты, которые использовали компонент до изменений будут продолжать использовать версию 1.1. Чтобы начать использовать наши изменения нужно поменять версию этого в зависимостях на 1.2.
Password encription
Чтобы не хранить пароли в конфигурации в их чистом видео используют md5 hash.
Зная пароль от maven удаленного репозитория мы можем сгенерировать hash.
для начала сгенерируем master-password.
— это базовый пароль, введите любой пароль.
Далее сгенерируем хэш для нашего пароля.
Вам нужно проделать вышесказанные пункты используя пароль пользователя, и передать ему файл
Что такое снимок Maven и зачем он нам нужен?
Я немного озадачен смыслом снимка Maven и почему мы его создаем?
Разница между «реальной» версией и версией снимка заключается в том, что снимки могут получать обновления. Это означает, что загрузка 1.0-SNAPSHOT сегодня может дать другой файл, чем загрузка вчера или завтра.
Как правило, зависимости моментальных снимков должны существовать только во время разработки, и ни одна выпущенная версия (т. Е. Не снимок) не должна зависеть от версии моментального снимка.
Когда вы создаете приложение, Maven будет искать зависимости в локальном хранилище. Если стабильная версия там не найдена, она будет искать удаленные репозитории (определенные в settings.xml или pom.xml ), чтобы получить эту зависимость. Затем он скопирует его в локальный репозиторий, чтобы сделать его доступным для следующих сборок.
Например, foo-1.0.jar библиотека считается стабильной версией, и если Maven найдет ее в локальном хранилище, она будет использовать ее для текущей сборки.
Теперь, если вам нужна foo-1.0-SNAPSHOT.jar библиотека, Maven будет знать, что эта версия нестабильна и подвержена изменениям. Вот почему Maven будет пытаться найти более новую версию в удаленных хранилищах, даже если версия этой библиотеки найдена в локальном хранилище. Однако эта проверка производится только один раз в день. Это означает, что если у вас есть foo-1.0-20110506.110000-1.jar (то есть эта библиотека была сгенерирована 2011/05/06 в 11:00:00) в вашем локальном репозитории, и если вы снова запустите сборку Maven в тот же день, Maven не будет проверять репозитории для более новой версии.
Maven предоставляет вам способ изменить эту политику обновления в определении вашего хранилища:
где XXX может быть:
Руководство по Maven. Snapshots.
Любое большое приложение состоит из нескольких модулей и, чаще всего над каждым модулем программы работает отдельная команда. Например, одна команда работает над бизнес логикой приложения и они используют проект business-logic (business-logic.jar.1.0), а другая команда работает на внешним видом приложения и разрабатывает проект app-front-end (app-front-end.jar:1.0).
В этом случае может случиться такая ситуация, при которой команда, которая работает над бизнес-логикой и они выпускают обновления каждую неделю и выкладывают его на удалённый репозиторий.
Таким образом, если эта команда часто выкладывает обновления, то можем произойти следующее:
Для того, что исправить эту ситуацию используется концепция snapshot.
Snapshot
Snapshot – это специальная версия, которая показывает текущую рабочую копию. При каждой сборке Maven проверяет наличие новой snapshot версии на удалённом репозитории.
В этом случае, команда business-logic будет выпускать snapshot своего обновления на репозиторий в виде business-logic:1.0-SNAPSHOT замещая предыдущий jar файл.
Snapshot и Версия
В случае с версией, если Maven однажды загрузил версию business-logic:1.0, то он больше не будет пытаться загрузить новую версию 1.0 из репозитория. Для того, чтобы скачать обновлённый продукт business-logic должен быть обновлён до версии 1.1.
В случае со snapshot, Maven автоматически будет подтягивать крайний snapshot (business-logic:1.0-SNAPSHOT) каждый раз, когда команда front-end будет выполнять сборку своего проекта.
Вот как это выглядит в pom.xml файле:
front-end pom.xml
business-logic pom.xml
На этом мы заканчиваем изучение snapshot-ов.
В следующей статье мы рассмотрим управление зависимостями.
A large software application generally consists of multiple modules and it is common scenario where multiple teams are working on different modules of same application. For example, consider a team is working on the front end of the application as app-ui project (app-ui.jar:1.0) and they are using data-service project (data-service.jar:1.0).
Now it may happen that team working on data-service is undergoing bug fixing or enhancements at rapid pace and they are releasing the library to remote repository almost every other day.
Now if data-service team uploads a new version every other day, then following problems will arise −
data-service team should tell app-ui team every time when they have released an updated code.
app-ui team required to update their pom.xml regularly to get the updated version.
To handle such kind of situation, SNAPSHOT concept comes into play.
What is SNAPSHOT?
SNAPSHOT is a special version that indicates a current development copy. Unlike regular versions, Maven checks for a new SNAPSHOT version in a remote repository for every build.
Now data-service team will release SNAPSHOT of its updated code every time to repository, say data-service: 1.0-SNAPSHOT, replacing an older SNAPSHOT jar.
Snapshot vs Version
In case of Version, if Maven once downloaded the mentioned version, say data-service:1.0, it will never try to download a newer 1.0 available in repository. To download the updated code, data-service version is be upgraded to 1.1.
In case of SNAPSHOT, Maven will automatically fetch the latest SNAPSHOT (data-service:1.0-SNAPSHOT) every time app-ui team build their project.
app-ui pom.xml
app-ui project is using 1.0-SNAPSHOT of data-service.
data-service pom.xml
data-service project is releasing 1.0-SNAPSHOT for every minor change.
Let’s open the command console, go to the C:\ > MVN > app-ui directory and execute the following mvn command.
Maven will start building the project after downloading the latest SNAPSHOT of data-service.
Делаем релизы с помощью Maven в Java
О чем эта статья?
Что такое релиз и с чем его едят
Для себя релиз я определяю, как закрепление определенного набора функциональности. Закрепляя функциональность, вы говорите: «Эта версия продукта содержит в себе возможность создавать новый документ, перелистывать страницы пальцем или запускать ракеты в космос.» Хорошей практикой является ведение списка закрепленной функциональности в баг-трекинговой системе, позволяя ребятам из QA быстро и просто определить, что умеет ваш релиз, а чего он не может, сказать, что где в вашу систему закралась ошибка и прочее-прочее-прочее.
Рассмотрим пример небольшого проекта. Представим себе, что городской зоопарк заказал нам разработать систему мониторинга состояния животных: в каких вольерах они живут, какой смотритель за ними ухаживает. Так же нужно информировать смотрителя с помощью sms о том, что животное нуждается в уходе.
Пусть проект будет сделан для Web и имеет следующую структуру:
zoo
|—zoo-web
|—zoo-sensor-server
Релизом для нас будет war, который мы можем задеплоить на веб-сервер, и zip c небольшим сервером, принимающим сообщения от датчиков в вольерах с животными.
Нумерация релизов
Тем временем в зоопарке
Итак, мы договорились дирекцией зоопарка, что перед запуском полноценного продукта, мы дадим им три промежуточные версии. Первая — будет содержать реализацию сервера, собирающего информацию с сенсоров в вольерах. Веб часть будет очень простой, выводящей метрики в неподготовленном виде. Вторая — будет содержать полноценный экран с информацией по вольерам, возможностями сортировки и прочее. Третья — будет содержать функциональность оповещения служащих о необходимых действиях через смс. И лишь когда мы все соберем, и клиенту все понравится — мы выпустим финальный релиз.
Дадим каждой из промежуточных версий имена 0.1.0, 0.2.0, 0.3.0 соответственно.
Первая цифра 0, потому что наш главный релиз еще не вышел, это лишь промежуточный результат.
Вторая цифра равна номеру поставки. Третья — 0, потому что мы считаем, что в ней нет багов на момент сборки.
Когда третья цифра равна 0, ее часто не пишут: 0.1, 0.2, 0.3. 
Alpha, Beta и прочие RC
Перед тем, как поставить релиз клиенту, даже промежуточный, он должен пройти QA процесс. Подходы к выпуску релизов для тестирования так же могут различаться, но в своих проектах я стараюсь использовать понятие Release Candidate.
Перед выпуском релиза x.y вы собираете x.y-RC1, x.y-RC2 и так далее, пока QA не скажет вам, что релиз стабилен и готов в UAT или Production.
Тогда последний RC становиться тем самым долгожданным релизом.
В любом коде существуют ошибки. И пользователь с радостью их найдет. В процессе саппорта заводятся новые баги, вы их правите и должны предоставить версию с исправлениями. Для этого собираются баг-фикс релизы.
Например, вы выпустили версию 0.1.0, и в ходе реальной работы выяснилось, что данные датчика температуры неправильно обрабатываются. Выпускается релиз 0.1.1, который исправляет досадное недоразумение.
Финальный релиз и далее
После серии из промежуточных поставок вы собираете 1.0-RC, заканчиваете процесс QA и собираете 1.0. Если впоследствии заказчик захочет функциональность автоматического открытия клеток по ночам, чтобы животные могли порезвиться, и вы напишите и соберете 1.1. Найдет пару десяток сотню багов и вы выпустите 1.1.47.
Если он вдруг захочет написать все заново, красивее и круче, то вам скорее всего понадобиться 2.0, потом 2.1.45 и так далее, и так далее.
Бранч при выпуске релиза
Почему релиз это больше, чем сборка war
Запоминаем состояние кода
Для этого используется теги. Теги в системе контроля версий, это имя закрепленное за ревизией. Для пользовательского взгляда, тег это такая же папка с исходным кодом, но ее состояние закреплено на момент создания тега. И не надо использовать теги как бранчи.
Выкладываем собранный продукт
Для хранения и обеспечения доступа к собранному продукту, вы можете использовать даже шару на внешнем сервере. В промышленную разработку Maven приносит понятие репозитория. В репозиториях хранятся артефакты, из репозитория можно взять артефакт. Репозиторий структурирует артефакты по группам, именам и версиям.
Все вместе
maven-release-plugin
maven-release-plugin — это инструмент взаимодействия между системой контроля версий и репозиторием, позволяющий выполнить релиз с помощью нескольких команд. Плагин выполняет за тебя весь процесс релиза от начала и до конца.
Настройка плагина
Для работы плагина ему необходима следующая информация в pom.xml главного модуля вашего проекта:
Информация о системе контроля версий
Во-первых, нам надо указать, где храниться исходный код проекта. Для этого используется стандартный для Maven тег:
Конфигурация параметров сборки
Для того, чтобы задать параметры самого релиза используется подключение плагина в секцию
Общие требования
Создаем релиз zoo-0.1
Соберем релиз первой поставки для нашего зоопарка. У нас на руках транк с версией 0.1-RC3-SNAPSHOT. QA команда сообщила нам, что RC2 был достаточно хорош, чтобы мы могли делать релиз.
Создание бранча для релиза — release:branch
Этот пункт нужно выполнять, только если вы собираете релиз с основной или дополнительной функциональностью. Если бы мы собирали багфиксинг релиз zoo-0.1.2, то этот пункт мы бы пропустили.
Если мы собираем Release Candidate, то этот шаг так же пропускаем.
Для создания бранча нужно выполнить:
В ходе выполнения, Maven спросит нас, какая следующая версия для транка, по умолчанию предложив 0.2-SNAPSHOT.
What is the new working copy version for «Zoo»? (com.zoo:zoo) 0.2-SNAPSHOT:
Подготовка к релизу — release:prepare
Maven последовательно спросит нас номер собираемой версии, название для тега и номер следующей версии:
На последний вопрос ответим ему 0.1.1-SNAPSHOT, ведь это и есть первый будущий багфикс релиз.
Выпуск релиза — release:perform
Фаза выполнения релиза включает в себя чекаут исходного кода из тега и сборку его (обычно до фазы deploy). Да, именно так, чекаут исходного кода из тега. Зачем это нужно, если у нас уже есть исходный код рабочей копии? Потому что Maven хочет быть уверен, что эта сборка будет идентична той, что потом можно сделать выбрав тег вручную.
Для завершения релиза надо выполнить:
На этот раз вас ничего не будут спрашивать, просто сделают все что надо. Результатом будет выложенный в общий репозиторий артефактов релиз.