Во время сборки той зависимости ей нужно будет подставить в версию номер коммита, например, с помощью mvn versions:set -DnewVersion=... .

Однако версия не должна содержать только коммит потому как ты можешь несколько раз собраться из одного и того же коммита. Туда еще должен входить какой-то порядковый build number. Он и за сортировку будет отвечать (нам часто интересно знать какая версия более поздняя). Или включать в версию timestamp с точностью эдак до секунды.

Т.к. тут много устаревших советов, хотел бы пролить свет на современные CI & CD подходы к ветвлению и релизам:
1. Ветки мы стараемся не использовать. Все в одной ветке, aka trunk-based development & branching by abstraction. Если не получается, ну тогда создаем короткоживущие ветки которые стараемся максимально быстро влить обратно в master. Релизные ветки в современных продуктах не должны использоваться если мы не поддерживаем сразу несколько релизов .
2. Потенциально каждый коммит может быть релизнут. Поэтому в версии не должно быть:
а) Веток или тегов, потому как это значит мы сначала решили что релизить, а потом зарелизили (а надо наоборот - по потому прошла
ли сборка автоматический пайплайн и ручные проверки мы определяем годится ли она в релизы).
б) "Красивых" релизных версий типа x.y.z. Опять же - потому как заранее мы не можем (не должны) знать релизная ли это версия. Вполне адекватной версией будет обычный Build Number. Можно x.y.z-build-number, можно "снапшотные" мавен версии типа x.y.z-timestamp-build-number.
3. Т.е. потому как каждая сборка может быть релизнута - каждая версия (будь то релиз или нет) должны иметь одинаковый вид.

Коммит можно хранить в версии (добавляя туда также build no), но от этого обычно ни холодно, ни жарко. Коммит можно и просто внутрь артефакта писать и отдавать по /version.

Не понял, почему он не компилируется? Если мы следуем Continuous Integration, то каждый пуш в мастер должен быть зеленым. Если это не так, то либо быстро-быстро чиним, либо откатываем. В общем-то при работе с ветками мы должны придерживаться той же стратегии.
maytonМне нравится подход GitLab flow при котором есть несколько осей разработки. Dev/QA/UAT/Master
(их может быть больше и другие названия но суть одинакова).Ох, счас видимо каждый создатель Git Server'a должен создать XXX Flow :) Если не учитывать лишних merge commit'ов (ох я представляю что в истории творится), лишних пересборок одного и того же под каждый энв, лишних веток про которые нужно помнить и удалять после релизов, лишних слложностей в скриптах - жить можно.

Вот только CI & CD - это о том чтоб не делать лишнего. Деплой в прод - это про деплой, а не про "пересобрать все заново и задеплоить уже другую версию". Один из постулатов Continuous Delivery - build once, deploy everywhere. А тут, переконфигурили nexus/jenkins и собралась уже какая-то чуть другая версия и пошла так в прод (но сначала подождали пока через пайплайн снова пройдет)..

Но в принципе не самая худшая схема из тех что я видел. Не GitFlow, и то радость.

Не понял, про какую часть CD вопрос? Если про пайплайн, то обычный Jenkins. Вот только деплой бы для секурности вынести в отдельный инструмент (а женкинс его дергает), но я по старинке пока - женкинсом делаю.
PetroNotC SharpПонятно что можно коммитить локально не заливая на сервак.
Ну а как твой код посмотрит тогда твой начальник?Вопрос про Code Review? Есть разные подходы:
- Micro code reviews с Gerrit'ом
- Post-push code review (мое название), если доверяем разработчикам
- Создание ветки для PR. Но тут ветка создается только как инструмент для PR.

Через reference, но не через ветку. Но это и не важно потому как это лишь технические детали того как работает Gerrit. Сами разработчики веток и прочих reference'ов не создают для код ревью.
maytonВнимание человека который смотрит в логи или в графики мониторинга - стоит дорого.
Никак оно не удешевляется. Поэтому с этой точки зрения мне вообще плевать сколько раз конвейер CI/CDДак это и есть время сотрудников. Окончания конвейера нужно дождаться чтоб делать ручные проверки. И его нужно дождаться для релиза. Бывает нужен хот фикс какой-то, а ждать его приходится часами. Потому как нужно автоматические проверки прогнать (системные функциональные и нагрузочные тесты очень медленная роскошь), а потом еще и вручную что-то проверить. А что если по-середине что-то упало? Надо дофиксить и заново запустить. Так вот день и проходит.

В общем и целом лишние ветки приводят к увеличению как Lean'овского Lead Time, так и TOC'овского Inventory Costs.

Андрей Панфилов, CD как раз и решает все эти проблемы одним нажатием кнопки. Я даже часто это нажатие на плечи QA перекладываю, ведь они решают что сборка достойна.
Андрей Панфилов- сформировать ранлист, где указаны определенные вехи и продолжительность операцийЭто все в скрипте.
Андрей Панфилов- согласовать (ну и назначить) время среди всех заинтересованных владельцев систем, а не только целевойКак правило нет никакой необходимости. Разве что функционал сильно поменялся и мы хотим тренинг провести для сотрудников.
Андрей Панфилов- оповестить пользователей о предстоящей недоступности (мне вот, к примеру, банк присылает оповещения что онлайн-кабинет не будет работать в определенный промежуток времени)CD предполагает zero-downtime deployment (blue-green deployment, canary releases). Я последний раз деплоил с даунтаймом 10 лет назад (не, ну лукавлю - у меня были несколько релизов с даунтаймом даже во времена CD, но это большое исключение).
Андрей Панфилов- согласовать доступность ключевых сотрудников на случай если что-то пойдет не по плануС трудом припоминаю случаи когда что-то шло не так (CD от этого защищает), но наверно может быть. Для этого нужен либо деплой новой версии с фиксом (т.е. нужно это делать в рабочее время когда есть разрабы) если фикс быстрый, либо просто деплой предыдущей версии. Если база меняется только аддитивно (никаких rename/drop используемых колонок), то это piece of cake.
Андрей Панфилов- убедиться что из резервных копий можно-таки восстановитьсяЭто тоже легко автоматизируется и должно проверяться на постоянной основе. Где позволительно, резервные копии нужно накатывать на какие-то из дев окружений (PREPROD?), это же защитит от плохих миграций которые проходят везде кроме PROD'a.
Андрей Панфилов- в час Х создать резервные копии, если необходимо
- что-то куда-то накатить
- прогнать смок-тесты
Автоматизируется
Андрей Панфилов- оповестить, что систему можно проверятьНе знаю кому и зачем это надо. Это просто "пресс релиз".
Андрей Панфилови вот с моей точки зрения шаг "что-то куда-то накатить" даже не имеет смысла автоматизировать:
- во-первых, он не особо-то и много времени занимает
Во-первых времени это занимает прилично, т.к. это не единоразовая активность. Особенно учитывая все шаги с бекапами и пр. Во-вторых это очень ответственная процедура и в ней не должно быть ошибок. Для этого мы описываем ее в скриптах, которые тестируются на всех окружениях прежде чем будет применяться на проде.
Андрей Панфилов- во-вторых, за это кто-то получает зарплатуСтранный аргумент, за ковку подков тоже когда-то получали зарплату.
Андрей Панфилов- в-третьих, от релиза к релизу шаги меняются и нет никакого смысла это автоматизироватьПоследний раз менял скрипты даже не знаю когда.. 4 года назад наверно. И так в каждом проекте в которых я реализовывал CI/CD - скрипты создаются на начальных этапах и про них забывают. Разве что захотелось на какой-то новый софт перейти.
Андрей Панфиловоднако все что сейчас существует на рынке, и в особенности в опенсорсе, даже эту задачу автоматизировать толком не в состоянии, здесь не особо вижу смысла накидывать кучу примеров в качестве подтверждения мысли, но в целом видится так, что все эти "автоматизации" зиждятся на трех китах:
- у заказчика неправильный дизайн приложения и нужно его менять
- у заказчика кривая архитектура и нужно ее менять
- ну мы тут у себя что-то запускали, а на проде внезапно что-то пошло не так, виноват дизайн и архитектураНе понимаю о каких инструментах речь. CI/CD - это больше культурная и процессуальная вещь, изменения должны произойти в головах людей. Скрипты нужно самим написать, не знаю какие бы инструменты тут могли помочь. Скрипты прийдется скорей всего в каждом проекте заново писать, как и код (эх..).

Андрей Панфиловну вот ваши цитирования по строчке не вызывают никакого желания вступать в дальнейшую дискуссиюНе понял - ожидается что я просто пропущу половину из написанного и не прокомментирую?
Андрей ПанфиловДавайте так: если все по вашему мнению "автоматизируется", то, будте добры, назовите хотя бы название продукта, где все что я хочу реализовано (а не то что какой-то шаг якобы не нужен потому что вы с ним не сталкивались), а не слово "Jenkins" где все откровенно лепится из говна и палокДак ты против того что "все автоматизируется" или против скриптов? Я не утверждал что есть какой-то мифический инструмент который за нас все сделает. Нам нужно написать скрипты , магии не существует. Будет ли говно и палки или что там еще - ну это кто как напишет. Но работающую автоматизацию можно сделать даже из говна и палок. Это все равно будет намного лучше ручного вмешательства.
Андрей Панфиловну или по крайней мере попробуйте доказать свое утверждение, что шаги инсталляции никогда не меняютсяЭт что за выдумки, я где-то писал что они никогда не меняются? Я говорил про "редко".
Андрей Панфиловс учетом того что бывают миграции данных, которые идут довольно долго и для ускорения процесса что-то может запускаться параллельно, а что-то должно выполняться строго последовательноУ меня были миграции по неделе и ничего не пришлось менять в скриптах, все решалось исключительно поддержкой обратной совместимости в новых релизах пока шла миграция. Наверняка бывают какие-то исключения когда прийдется что-то вручную промигрировать или что-то в этом роде, но это все же исключения, я бы на них внимания не заострял.

Вообще удивительно что в 2021ом мы ведем такие дискуссии. Уже 5 лет назад казалось что ручные манипуляции во время деплоя - это каменный век.

В такой постановке - никакой. Вот где есть разница:
1. push to branch -> push to branch -> push to branch -> review -> master
2. push to branch -> review -> master -> push to branch -> review -> master -> push to branch -> review -> master

Т.е. мы не доводим фичу до конца в ветке, а потом вливаем. А стараемся вливать периодически то что есть, что-то что еще не закончено. Это апогей Continuous Integration'а.

Андрей Панфилов , я наверно повторюсь, но безотносительно того говно или не говно bash, хорошо на нем пишут или плохо - это все равно лучше ручного вмешательства.
Андрей ПанфиловСо стороны ДИТ деплой наверное уже лет как 30 полностью автоматизирован: создается work order, он кем-то закрывается, каким именно образом он закрывается - это уже проблема вполне конкретного подразделения, они могут хоть пляски с бубном устраивать, главное чтобы work order был закрыт.Многие путаются в термине DevOps - кто-то думает что это люди. На самом деле этот термин значит Devs & Ops команды работающие вместе . В более широком смысле это значит культуру компании, где не "моя хата с краю", а разные роли и департаменты работают друг с другом совместно чтоб получить хороший результат. Не каждый работает на свою метрику, а наоборот - он может пожертвовать своим временем ради других если это повышает производительность организации в целом . Т.е. мы боремся не за локальный, а именно за глобальный оптимум.

Это именно то к чему IT пришло чуть больше 10 лет назад - такая схема приводит к более успешным проектам и компаниям. А "заводится work order - они там пусть че хотят, то и делают" - это что-то из 90ых. Программисты должны разбираться на каких OS у них деплой, с какой конфигурацией. И без их помощи Ops инженеры не смогут сделать свою работу хорошо, ведь одна из их основных задач - полностью автоматизировать деплой. Именно от разработчиков зависит можно ли реализовать blue-green deploy, будут ли они релизить маленькие куски (с помощью branching by abstraction, feature toggles и пр) или большие (после которых возникает намного больше проблем), как что логируется и пр, пр.

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

Да и в целом это повышает мораль, CI/CD - это спокойные проекты, без стрессов, где релиз всегда проходит гладко.