powered by simpleCommunicator - 2.0.29     © 2024 Programmizd 02
Map
Форумы / Java [игнор отключен] [закрыт для гостей] / Maven и зависимость по коммиту гита
25 сообщений из 48, страница 1 из 2
Maven и зависимость по коммиту гита
    #40083671
ahmaroot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем привет.

Как в pom.xml в качестве version в зависимости указать конкретный коммит?
Например, как то так:

Код: java
1.
2.
3.
4.
5.
<dependency>
            <groupId>com.someCompanyName</groupId>
            <artifactId>service-client</artifactId>
            <version>121213123123213123</version>
        </dependency>
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083676
SpringMan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Очевидно, что вначале надо выложить в репозиторий с номером коммита. Это зависит от: как это деплоится сейчас и какие инструменты ci/cd используются
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083698
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ahmaroot,
Одна версия по логике это несколько коммитов разных прогеров.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083705
Во время сборки той зависимости ей нужно будет подставить в версию номер коммита, например, с помощью mvn versions:set -DnewVersion=... .

Однако версия не должна содержать только коммит потому как ты можешь несколько раз собраться из одного и того же коммита. Туда еще должен входить какой-то порядковый build number. Он и за сортировку будет отвечать (нам часто интересно знать какая версия более поздняя). Или включать в версию timestamp с точностью эдак до секунды.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083706
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Version order - важное замечание.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083755
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ahmaroot
Всем привет.

Как в pom.xml в качестве version в зависимости указать конкретный коммит?
Например, как то так:

Код: java
1.
2.
3.
4.
5.
<dependency>
            <groupId>com.someCompanyName</groupId>
            <artifactId>service-client</artifactId>
            <version>121213123123213123</version>
        </dependency>



Не надо так делать.
ИМХО можно использовать ветки-релизы для соответствующих версий артефакта.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083773
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для работы с версиями годятся branches и tags.

Теги обычно используют для релиза. Чтобы отметить в истории master какую-то фиксированную
точку и иметь к ней возможность вернуться.

Код: java
1.
2.
git tag -a v-01 -m "V-01 with super-puper feature"
git push --follow-tags



Git revision number не годятся потому-что их смысл несколько иной. Я например на 1 разработку
могу сделать много коммитов и много rev-numbers зайдет в фича-бранч.

Тоесть финалом разработки является бранч или тег.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083814
Т.к. тут много устаревших советов, хотел бы пролить свет на современные 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.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083822
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ahmaroot,

у меня все крайне тупо организовано:
- принятие ПР в develop "означает", он прошел тесты, ревью и потенциально можно "куда-то" установить
- гитлаб об этом факте радостно сообщает в Jenkins, а тот запускает что-то в духе:

Код: java
1.
2.
3.
4.
5.
mvn -e --batch-mode -Prelease release:clean release:prepare \
 -DreleaseVersion=${pom.version%-SNAPSHOT}-commitId \
 -DdevelopmentVersion=pom.version \
 -DpushChanges=false \
 -DpreparationGoals="clean deploy"


- что в свою очередь собирает все и публикует артефакты в nexus

вам также наверное можно в проект добавить гитовый submodule, прописать его в реакторе и переключаться на нужный коммит
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083842
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev,
Как это все в одной ветке?
Подробнее.
Пилят 20 прогеров 20 фич с новым кодом.
Все 20 в мастер коммитят?
Например, в конце дня 20 челов скинули НЕКОМПИЛИРУЕМЫЙ код в мастер ветку?
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083859
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не одобряю и не осуждаю подход Станислава. Просто каждая команда в зависимости
от условий выбирает себе как работать. Чаще всего как-то коллегиально это всё происходит.
Собрались. И очень быстро решили. Это как на пикнике - люди очень быстро решают где поставить
палатку и развести огонь. Интуитивно.

Мне нравится подход GitLab flow при котором есть несколько осей разработки. Dev/QA/UAT/Master
(их может быть больше и другие названия но суть одинакова).

Слева направо оси - это вечно-живущие бранчи откуда делают перенос (merge) разработанных
фичей или баго-фиксов слева направо. Перенос можно сделать когда угодно. Это вызывает
триггеры CI/CD сред которые пересобирают енвы и деплоят все что надо. При сломанных тестах
или отрицательном аксептансе например на UAT - зажигается красная лампочка напротив оси
и всем видно что сломано и где.

При таком подходе закинуть в мастер 20 бизнес фич которые сломаны просто невозможно. Т.к. они не пройдут
все quality-gates еще на фазах QA/UAT.

Есть еще лекция Бугаенко на тему автоматизации этих quality-фильтров. Маэстро ратует за максимальную
автоматизацию проверок таким образом что в принципе сломать мастер невозможно. Я не совсем согласен
с ним. Однако те среды и стратегии которые я видел были часто настолько плохи что даже подход Бугаенко
был-бы благом.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083878
PetroNotC Sharp
Все 20 в мастер коммитят?
Например, в конце дня 20 челов скинули НЕКОМПИЛИРУЕМЫЙ код в мастер ветку?
Не понял, почему он не компилируется? Если мы следуем 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, и то радость.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083879
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev,
Да банально гит не даст перейти по истории или по веткам если не закоммичено. Будет сообщение "Закоммиться или все потеряешь!)))).
Сам гит так работает.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083880
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev,
Понятно что можно коммитить локально не заливая на сервак.
Ну а как твой код посмотрит тогда твой начальник?
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083881
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev
Вот только CI & CD - это о том чтоб не делать лишнего. Деплой в прод - это про деплой, а не про "пересобрать все заново и задеплоить уже другую версию". Один из постулатов Continuous Delivery - build once, deploy everywhere. А тут, переконфигурили nexus/jenkins и собралась уже какая-то чуть другая версия и пошла так в прод (но сначала подождали пока через пайплайн снова пройдет)..


а что в опенсорсе есть именно для CD? я как-то давно смотрел (лет 5 назад) было все совсем печально: либо за деньги, либо лапша из непонятных скриптов, сейчас складывается впечатление, что "проблема сама исчезла", потому что деплой заменили на разворачивание контейнеров (ну и лапша переехала в Dockerfile ).
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083882
Андрей Панфилов
Stanislav Bashkyrtsev
Вот только CI & CD - это о том чтоб не делать лишнего. Деплой в прод - это про деплой, а не про "пересобрать все заново и задеплоить уже другую версию". Один из постулатов Continuous Delivery - build once, deploy everywhere. А тут, переконфигурили nexus/jenkins и собралась уже какая-то чуть другая версия и пошла так в прод (но сначала подождали пока через пайплайн снова пройдет)..


а что в опенсорсе есть именно для CD? я как-то давно смотрел (лет 5 назад) было все совсем печально: либо за деньги, либо лапша из непонятных скриптов, сейчас складывается впечатление, что "проблема сама исчезла", потому что деплой заменили на разворачивание контейнеров (ну и лапша переехала в Dockerfile ).
Не понял, про какую часть CD вопрос? Если про пайплайн, то обычный Jenkins. Вот только деплой бы для секурности вынести в отдельный инструмент (а женкинс его дергает), но я по старинке пока - женкинсом делаю.
PetroNotC SharpПонятно что можно коммитить локально не заливая на сервак.
Ну а как твой код посмотрит тогда твой начальник?Вопрос про Code Review? Есть разные подходы:
- Micro code reviews с Gerrit'ом
- Post-push code review (мое название), если доверяем разработчикам
- Создание ветки для PR. Но тут ветка создается только как инструмент для PR.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083886
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev,
Угу.
Итого
- Geritt не про то. Так как юзкейс что я сказал выше шире чем превью кода,
- твое название это несолидно брат)))) Это по русски "проверить когда закоммитил и уже поздно?"
- создание ветки. Вот оно!
О чем я и говорю. С одним мастером неудобно.
Кому нравится ветка на разработчика. Кому - ветка на фичу.
Монопесуально.
Но факт в том что ветки нужны. И больше одной.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083889
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev,
"
При переходе на Git вы должны привыкнуть к тому, что для того, чтобы поделиться фиксацией с коллегами, требуется три шага. В большинстве систем контроля версий есть только один шаг: передача из рабочей копии на общий сервер. В Git вы добавляете файлы из рабочей копии в область подготовки. После этого вы фиксируете их в своем локальном репозитории. Третий шаг - отправка в общий удаленный репозиторий. После того, как вы привыкнете к этим трем шагам, следующей проблемой станет модель ветвления.
"
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083896
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev,

Хммм. Почитал про Gerrit.
Получается что он работает опять таки через доп ветку гита
авторGerrit - система совместной инспекции кода, написанная сотрудником Google и используемая при написании Android OS. Цель Gerrit состоит в том, чтобы заставлять разработчиков просматривать код друг друга до попадания оного в общую ветку проекта. Реализовав некую функциональность, разработчик не посылает плод своих трудов напрямую в активную ветку, но отправляет его в отдельно создаваемый для этой цели бранч
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083923
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083931
PetroNotC Sharp
Хммм. Почитал про Gerrit.
Получается что он работает опять таки через доп ветку гита
Через reference, но не через ветку. Но это и не важно потому как это лишь технические детали того как работает Gerrit. Сами разработчики веток и прочих reference'ов не создают для код ревью.
maytonВнимание человека который смотрит в логи или в графики мониторинга - стоит дорого.
Никак оно не удешевляется. Поэтому с этой точки зрения мне вообще плевать сколько раз конвейер CI/CDДак это и есть время сотрудников. Окончания конвейера нужно дождаться чтоб делать ручные проверки. И его нужно дождаться для релиза. Бывает нужен хот фикс какой-то, а ждать его приходится часами. Потому как нужно автоматические проверки прогнать (системные функциональные и нагрузочные тесты очень медленная роскошь), а потом еще и вручную что-то проверить. А что если по-середине что-то упало? Надо дофиксить и заново запустить. Так вот день и проходит.

В общем и целом лишние ветки приводят к увеличению как Lean'овского Lead Time, так и TOC'овского Inventory Costs.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083946
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev,
авторСами разработчики веток и прочих reference'ов не создают для код ревью.
У меня сосед тоже ветки боится создавать. Каждый день копирует просто папку с исходниками на диске. 365 папок в году))))
ОК. Ваши разрабы не едят мяса. Это религия.
Удачи!
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083965
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я держу 2 копии проекта в двух фолдерах. Чтоб в 2 среды разработки открывать один и тот-же проект в разных бранчах
и стоять в двух дебаггерах одновременно.

Я понимаю, что это - антипаттерн работы, но мне почему-то так удобно. Если кто знает оптимизацию или автоматизацию
подобного - сообщите plz.
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083969
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Я понимаю, что это - антипаттерн работы, но мне почему-то так удобно. Если кто знает оптимизацию или автоматизацию
подобного - сообщите plz.
Очевидно же: нужно два разных десктопа
...
Рейтинг: 0 / 0
Maven и зависимость по коммиту гита
    #40083971
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфилов
mayton
Я понимаю, что это - антипаттерн работы, но мне почему-то так удобно. Если кто знает оптимизацию или автоматизацию
подобного - сообщите plz.
Очевидно же: нужно два разных десктопа
...
Рейтинг: 0 / 0
25 сообщений из 48, страница 1 из 2
Форумы / Java [игнор отключен] [закрыт для гостей] / Maven и зависимость по коммиту гита
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]