|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Всем привет. Как в pom.xml в качестве version в зависимости указать конкретный коммит? Например, как то так: Код: java 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2021, 22:48 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Очевидно, что вначале надо выложить в репозиторий с номером коммита. Это зависит от: как это деплоится сейчас и какие инструменты ci/cd используются ... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2021, 23:30 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
ahmaroot, Одна версия по логике это несколько коммитов разных прогеров. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 06:31 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Во время сборки той зависимости ей нужно будет подставить в версию номер коммита, например, с помощью mvn versions:set -DnewVersion=... . Однако версия не должна содержать только коммит потому как ты можешь несколько раз собраться из одного и того же коммита. Туда еще должен входить какой-то порядковый build number. Он и за сортировку будет отвечать (нам часто интересно знать какая версия более поздняя). Или включать в версию timestamp с точностью эдак до секунды. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 08:47 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Version order - важное замечание. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 08:59 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
ahmaroot Всем привет. Как в pom.xml в качестве version в зависимости указать конкретный коммит? Например, как то так: Код: java 1. 2. 3. 4. 5.
Не надо так делать. ИМХО можно использовать ветки-релизы для соответствующих версий артефакта. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 12:44 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Для работы с версиями годятся branches и tags. Теги обычно используют для релиза. Чтобы отметить в истории master какую-то фиксированную точку и иметь к ней возможность вернуться. Код: java 1. 2.
Git revision number не годятся потому-что их смысл несколько иной. Я например на 1 разработку могу сделать много коммитов и много rev-numbers зайдет в фича-бранч. Тоесть финалом разработки является бранч или тег. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 13:34 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Т.к. тут много устаревших советов, хотел бы пролить свет на современные 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. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 16:07 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
ahmaroot, у меня все крайне тупо организовано: - принятие ПР в develop "означает", он прошел тесты, ревью и потенциально можно "куда-то" установить - гитлаб об этом факте радостно сообщает в Jenkins, а тот запускает что-то в духе: Код: java 1. 2. 3. 4. 5.
- что в свою очередь собирает все и публикует артефакты в nexus вам также наверное можно в проект добавить гитовый submodule, прописать его в реакторе и переключаться на нужный коммит ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 16:28 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, Как это все в одной ветке? Подробнее. Пилят 20 прогеров 20 фич с новым кодом. Все 20 в мастер коммитят? Например, в конце дня 20 челов скинули НЕКОМПИЛИРУЕМЫЙ код в мастер ветку? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 17:06 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Не одобряю и не осуждаю подход Станислава. Просто каждая команда в зависимости от условий выбирает себе как работать. Чаще всего как-то коллегиально это всё происходит. Собрались. И очень быстро решили. Это как на пикнике - люди очень быстро решают где поставить палатку и развести огонь. Интуитивно. Мне нравится подход GitLab flow при котором есть несколько осей разработки. Dev/QA/UAT/Master (их может быть больше и другие названия но суть одинакова). Слева направо оси - это вечно-живущие бранчи откуда делают перенос (merge) разработанных фичей или баго-фиксов слева направо. Перенос можно сделать когда угодно. Это вызывает триггеры CI/CD сред которые пересобирают енвы и деплоят все что надо. При сломанных тестах или отрицательном аксептансе например на UAT - зажигается красная лампочка напротив оси и всем видно что сломано и где. При таком подходе закинуть в мастер 20 бизнес фич которые сломаны просто невозможно. Т.к. они не пройдут все quality-gates еще на фазах QA/UAT. Есть еще лекция Бугаенко на тему автоматизации этих quality-фильтров. Маэстро ратует за максимальную автоматизацию проверок таким образом что в принципе сломать мастер невозможно. Я не совсем согласен с ним. Однако те среды и стратегии которые я видел были часто настолько плохи что даже подход Бугаенко был-бы благом. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 17:52 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
PetroNotC Sharp Все 20 в мастер коммитят? Например, в конце дня 20 челов скинули НЕКОМПИЛИРУЕМЫЙ код в мастер ветку? 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, и то радость. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 19:14 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, Да банально гит не даст перейти по истории или по веткам если не закоммичено. Будет сообщение "Закоммиться или все потеряешь!)))). Сам гит так работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 19:17 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, Понятно что можно коммитить локально не заливая на сервак. Ну а как твой код посмотрит тогда твой начальник? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 19:19 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev Вот только CI & CD - это о том чтоб не делать лишнего. Деплой в прод - это про деплой, а не про "пересобрать все заново и задеплоить уже другую версию". Один из постулатов Continuous Delivery - build once, deploy everywhere. А тут, переконфигурили nexus/jenkins и собралась уже какая-то чуть другая версия и пошла так в прод (но сначала подождали пока через пайплайн снова пройдет).. а что в опенсорсе есть именно для CD? я как-то давно смотрел (лет 5 назад) было все совсем печально: либо за деньги, либо лапша из непонятных скриптов, сейчас складывается впечатление, что "проблема сама исчезла", потому что деплой заменили на разворачивание контейнеров (ну и лапша переехала в Dockerfile ). ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 19:20 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Андрей Панфилов Stanislav Bashkyrtsev Вот только CI & CD - это о том чтоб не делать лишнего. Деплой в прод - это про деплой, а не про "пересобрать все заново и задеплоить уже другую версию". Один из постулатов Continuous Delivery - build once, deploy everywhere. А тут, переконфигурили nexus/jenkins и собралась уже какая-то чуть другая версия и пошла так в прод (но сначала подождали пока через пайплайн снова пройдет).. а что в опенсорсе есть именно для CD? я как-то давно смотрел (лет 5 назад) было все совсем печально: либо за деньги, либо лапша из непонятных скриптов, сейчас складывается впечатление, что "проблема сама исчезла", потому что деплой заменили на разворачивание контейнеров (ну и лапша переехала в Dockerfile ). PetroNotC SharpПонятно что можно коммитить локально не заливая на сервак. Ну а как твой код посмотрит тогда твой начальник?Вопрос про Code Review? Есть разные подходы: - Micro code reviews с Gerrit'ом - Post-push code review (мое название), если доверяем разработчикам - Создание ветки для PR. Но тут ветка создается только как инструмент для PR. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 19:27 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, Угу. Итого - Geritt не про то. Так как юзкейс что я сказал выше шире чем превью кода, - твое название это несолидно брат)))) Это по русски "проверить когда закоммитил и уже поздно?" - создание ветки. Вот оно! О чем я и говорю. С одним мастером неудобно. Кому нравится ветка на разработчика. Кому - ветка на фичу. Монопесуально. Но факт в том что ветки нужны. И больше одной. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 19:43 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, " При переходе на Git вы должны привыкнуть к тому, что для того, чтобы поделиться фиксацией с коллегами, требуется три шага. В большинстве систем контроля версий есть только один шаг: передача из рабочей копии на общий сервер. В Git вы добавляете файлы из рабочей копии в область подготовки. После этого вы фиксируете их в своем локальном репозитории. Третий шаг - отправка в общий удаленный репозиторий. После того, как вы привыкнете к этим трем шагам, следующей проблемой станет модель ветвления. " ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 19:48 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, Хммм. Почитал про Gerrit. Получается что он работает опять таки через доп ветку гита авторGerrit - система совместной инспекции кода, написанная сотрудником Google и используемая при написании Android OS. Цель Gerrit состоит в том, чтобы заставлять разработчиков просматривать код друг друга до попадания оного в общую ветку проекта. Реализовав некую функциональность, разработчик не посылает плод своих трудов напрямую в активную ветку, но отправляет его в отдельно создаваемый для этой цели бранч ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 20:25 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev Вот только CI & CD - это о том чтоб не делать лишнего. Деплой в прод - это про деплой, а не про "пересобрать все заново и задеплоить уже другую версию". Один из постулатов Continuous Delivery - build once, deploy everywhere. А тут, переконфигурили nexus/jenkins и собралась уже какая-то чуть другая версия и пошла так в прод (но сначала подождали пока через пайплайн снова пройдет).. Но в принципе не самая худшая схема из тех что я видел. Не GitFlow, и то радость. Ты заметил как последние лет 10-15 стремительно дешевеет мегабайт и мегфалоп? Одна контора которая торгует дисковыми стойками говаривала "Gigabytes - free, IOPS - cost". Всё подешевело. Виртуальных хостингов как грязи. Но вот что не стало дешевле - так это усилия специалистов техподдержки (даже индусов 1-st line) усилия разработчика и QA. Внимание человека который смотрит в логи или в графики мониторинга - стоит дорого. Никак оно не удешевляется. Поэтому с этой точки зрения мне вообще плевать сколько раз конвейер CI/CD стартует. Пускай хоть каждую минуту. Цена этого всего - успешный релиз. А сколько там в атмосферу улетит тепла - пускай Грета Тунберг считает вместе с коровами и самолётами. Я в этом смысле техногенный маньяк и консерватор. Стоит сервер - пусть работает. Вообще все эти стратегии - просто пустяки по сравнению с тем например сколько государства и большие корпорации вкладывают в глобальное слежение. Или сколько крипто-панки тратят на поддержку распределенных транзакций с майнингом. Вот такие пироги IMHO. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2021, 22:59 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
PetroNotC Sharp Хммм. Почитал про Gerrit. Получается что он работает опять таки через доп ветку гита maytonВнимание человека который смотрит в логи или в графики мониторинга - стоит дорого. Никак оно не удешевляется. Поэтому с этой точки зрения мне вообще плевать сколько раз конвейер CI/CDДак это и есть время сотрудников. Окончания конвейера нужно дождаться чтоб делать ручные проверки. И его нужно дождаться для релиза. Бывает нужен хот фикс какой-то, а ждать его приходится часами. Потому как нужно автоматические проверки прогнать (системные функциональные и нагрузочные тесты очень медленная роскошь), а потом еще и вручную что-то проверить. А что если по-середине что-то упало? Надо дофиксить и заново запустить. Так вот день и проходит. В общем и целом лишние ветки приводят к увеличению как Lean'овского Lead Time, так и TOC'овского Inventory Costs. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2021, 01:03 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, авторСами разработчики веток и прочих reference'ов не создают для код ревью. У меня сосед тоже ветки боится создавать. Каждый день копирует просто папку с исходниками на диске. 365 папок в году)))) ОК. Ваши разрабы не едят мяса. Это религия. Удачи! ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2021, 06:46 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Я держу 2 копии проекта в двух фолдерах. Чтоб в 2 среды разработки открывать один и тот-же проект в разных бранчах и стоять в двух дебаггерах одновременно. Я понимаю, что это - антипаттерн работы, но мне почему-то так удобно. Если кто знает оптимизацию или автоматизацию подобного - сообщите plz. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2021, 09:18 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
mayton Я понимаю, что это - антипаттерн работы, но мне почему-то так удобно. Если кто знает оптимизацию или автоматизацию подобного - сообщите plz. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2021, 09:26 |
|
Maven и зависимость по коммиту гита
|
|||
---|---|---|---|
#18+
Андрей Панфилов mayton Я понимаю, что это - антипаттерн работы, но мне почему-то так удобно. Если кто знает оптимизацию или автоматизацию подобного - сообщите plz. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2021, 09:28 |
|
|
start [/forum/topic.php?fid=59&msg=40083879&tid=2120394]: |
0ms |
get settings: |
17ms |
get forum list: |
5ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
35ms |
get topic data: |
4ms |
get forum data: |
1ms |
get page messages: |
482ms |
get tp. blocked users: |
1ms |
others: | 389ms |
total: | 936ms |
0 / 0 |