Простите, не очень понимаю. Кто мешает залезть в pom-файл в редакторе и изменить номер версии? Зачем таким извращённым способом его менять? Есть гипотеза у меня, что это на случай сильно автоматизированной сборки, когда Мавен из Дженкинса, к примеру, запускают. Верно ли понял? Всё равно это кажется неким извращением - с помощью плагина редактировать Pom.xml. Отредактировав, надо ведь закоммитить, не правда ли? Закоммитив, запушить. И всё это тоже с помощью плагинов делают? А если кормит или пуш не проходят, то вся сборка ломается. Не логичнее ли выставлять версии, коммитить и пушить руками?
Дмитрий, спасибо за классный вопрос! Нет ничего криминального в том, чтобы идти в pom файл и редактировать номер версии руками. Действительно, все эти подходы с плагинами гораздо сложнее. И особенно это так - если версионирование проекта не важно. НО - для случаев, когда версионирование важно, давайте попробуем проскалировать подход с ручным редактированием версии. В случае, когда есть один разработчик на проекте - он отвечает за смену версии. Когда потребуется он пойдёт и обновит версию в pom-файле. Когда разработчиков в команде больше одного - потребуется определить кто и когда будет обновлять версию. Уже на этом этапе нужно будет менять процесс разработки - договариваться об условиях и ответственности. Идём дальше - если у нас монолит и его редактирует множество разработчиков из разных команд - договориться о правилах уже вряд ли получиться. Поэтому точно потребуется изменение процесса разработки - выделение релиз-инженера, например. Из примеров выше, Вы можете заметить всё возрастающую сложность версионирования проекта с изменением условий (масштабов) разработки. И вот для подобных случаев и нужны подходы, подобные описанному в моём ролике. Далее, как Вы верно подметили - коммит с новой сборкой, в случае использования плагинов, должен кем-то где-то делаться. Обычно, в командах разработки решается вопрос о том, а что такое "новая версия" - это каждое изменение вмёрженное в какую-то ветку (будь то master, или release-ветка) или же это целый кластер изменений. И в зависимости от выбора - добавляется шаг обновления версии в проекте в тот или иной этап pipeline'а на CI. Ну и конкретно про CI - действительно, если инкремент версии в CI будет провален, то весь процесс сборки будет провален. И на самом деле - это хорошо. И вот почему - после успешной сборки, зачастую, собранный артифкат публикуется где-то (nexus, артифактори и т.д.) где он становится доступен под какой-то версией. Соответсвенно - не получилось инкрементировать версию - нет артифакта в nexus. То есть - смена версии в pom, по хорошему, должна стать частью процесса сборки. У такого автоматизированного подхода есть ещё плюсы: - в автоматизацию достаточно заложить правила инкремента версии (commit hash, semver и т.д.) и автоматически все команды разработки ему следуют - разработчики концентрируются на выполнении бизнес-задач, не тратя когнитивный ресурс на процесс выпуска очередной версии ну и наконец, практика авто-обновления версии довольно распространена. Я рассказал лишь об одном. В gradle есть свои плагины - например - github.com/ajoberstar/reckon Ещё раз - спасибо за хороший вопрос. Мне понравилось на него отвечать! С наступающим Новым Годом! 🤝
Спасибо большое, очень понятно и просто объяснили!!!!
Всегда пожалуйста! 🙏
Простите, не очень понимаю. Кто мешает залезть в pom-файл в редакторе и изменить номер версии? Зачем таким извращённым способом его менять? Есть гипотеза у меня, что это на случай сильно автоматизированной сборки, когда Мавен из Дженкинса, к примеру, запускают. Верно ли понял? Всё равно это кажется неким извращением - с помощью плагина редактировать Pom.xml. Отредактировав, надо ведь закоммитить, не правда ли? Закоммитив, запушить. И всё это тоже с помощью плагинов делают? А если кормит или пуш не проходят, то вся сборка ломается. Не логичнее ли выставлять версии, коммитить и пушить руками?
Дмитрий, спасибо за классный вопрос!
Нет ничего криминального в том, чтобы идти в pom файл и редактировать номер версии руками. Действительно, все эти подходы с плагинами гораздо сложнее. И особенно это так - если версионирование проекта не важно.
НО - для случаев, когда версионирование важно, давайте попробуем проскалировать подход с ручным редактированием версии. В случае, когда есть один разработчик на проекте - он отвечает за смену версии. Когда потребуется он пойдёт и обновит версию в pom-файле. Когда разработчиков в команде больше одного - потребуется определить кто и когда будет обновлять версию. Уже на этом этапе нужно будет менять процесс разработки - договариваться об условиях и ответственности. Идём дальше - если у нас монолит и его редактирует множество разработчиков из разных команд - договориться о правилах уже вряд ли получиться. Поэтому точно потребуется изменение процесса разработки - выделение релиз-инженера, например.
Из примеров выше, Вы можете заметить всё возрастающую сложность версионирования проекта с изменением условий (масштабов) разработки. И вот для подобных случаев и нужны подходы, подобные описанному в моём ролике.
Далее, как Вы верно подметили - коммит с новой сборкой, в случае использования плагинов, должен кем-то где-то делаться. Обычно, в командах разработки решается вопрос о том, а что такое "новая версия" - это каждое изменение вмёрженное в какую-то ветку (будь то master, или release-ветка) или же это целый кластер изменений. И в зависимости от выбора - добавляется шаг обновления версии в проекте в тот или иной этап pipeline'а на CI.
Ну и конкретно про CI - действительно, если инкремент версии в CI будет провален, то весь процесс сборки будет провален. И на самом деле - это хорошо. И вот почему - после успешной сборки, зачастую, собранный артифкат публикуется где-то (nexus, артифактори и т.д.) где он становится доступен под какой-то версией. Соответсвенно - не получилось инкрементировать версию - нет артифакта в nexus. То есть - смена версии в pom, по хорошему, должна стать частью процесса сборки.
У такого автоматизированного подхода есть ещё плюсы:
- в автоматизацию достаточно заложить правила инкремента версии (commit hash, semver и т.д.) и автоматически все команды разработки ему следуют
- разработчики концентрируются на выполнении бизнес-задач, не тратя когнитивный ресурс на процесс выпуска очередной версии
ну и наконец, практика авто-обновления версии довольно распространена. Я рассказал лишь об одном. В gradle есть свои плагины - например - github.com/ajoberstar/reckon
Ещё раз - спасибо за хороший вопрос. Мне понравилось на него отвечать! С наступающим Новым Годом! 🤝
@@fullstackguy Анвер, благодарю вас за скорый, развёрнутый и доброжелательеый ответ! И вас с наступающим Новым Годом!