Гость
Войти | Профиль | Очистить
Map
Действия ...
Форумы / Java [игнор отключен] [закрыт для гостей] / Maven и зависимость по коммиту гита / 25 сообщений из 48, страница 1 из 2
  1  все
13.07.2021, 22:48
    #40083671
ahmaroot
ahmaroot
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
Всем привет.

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

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

Однако версия не должна содержать только коммит потому как ты можешь несколько раз собраться из одного и того же коммита. Туда еще должен входить какой-то порядковый build number. Он и за сортировку будет отвечать (нам часто интересно знать какая версия более поздняя). Или включать в версию timestamp с точностью эдак до секунды.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.07.2021, 08:59
    #40083706
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
Version order - важное замечание.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.07.2021, 12:44
    #40083755
mad_nazgul
mad_nazgul
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
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
| Ответить | Цитировать | Написать  
14.07.2021, 13:34
    #40083773
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
Для работы с версиями годятся 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
| Ответить | Цитировать | Написать  
14.07.2021, 16:07
    #40083814
Stanislav Bashkyrtsev
Stanislav Bashkyrtsev
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
Т.к. тут много устаревших советов, хотел бы пролить свет на современные 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
| Ответить | Цитировать | Написать  
14.07.2021, 16:28
    #40083822
Андрей Панфилов
Андрей Панфилов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
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
| Ответить | Цитировать | Написать  
14.07.2021, 17:06
    #40083842
PetroNotC Sharp
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
Stanislav Bashkyrtsev,
Как это все в одной ветке?
Подробнее.
Пилят 20 прогеров 20 фич с новым кодом.
Все 20 в мастер коммитят?
Например, в конце дня 20 челов скинули НЕКОМПИЛИРУЕМЫЙ код в мастер ветку?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.07.2021, 17:52
    #40083859
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
Не одобряю и не осуждаю подход Станислава. Просто каждая команда в зависимости
от условий выбирает себе как работать. Чаще всего как-то коллегиально это всё происходит.
Собрались. И очень быстро решили. Это как на пикнике - люди очень быстро решают где поставить
палатку и развести огонь. Интуитивно.

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

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

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

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


а что в опенсорсе есть именно для CD? я как-то давно смотрел (лет 5 назад) было все совсем печально: либо за деньги, либо лапша из непонятных скриптов, сейчас складывается впечатление, что "проблема сама исчезла", потому что деплой заменили на разворачивание контейнеров (ну и лапша переехала в Dockerfile ).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.07.2021, 19:27
    #40083882
Stanislav Bashkyrtsev
Stanislav Bashkyrtsev
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
Андрей Панфилов
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
| Ответить | Цитировать | Написать  
14.07.2021, 19:43
    #40083886
PetroNotC Sharp
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
Stanislav Bashkyrtsev,
Угу.
Итого
- Geritt не про то. Так как юзкейс что я сказал выше шире чем превью кода,
- твое название это несолидно брат)))) Это по русски "проверить когда закоммитил и уже поздно?"
- создание ветки. Вот оно!
О чем я и говорю. С одним мастером неудобно.
Кому нравится ветка на разработчика. Кому - ветка на фичу.
Монопесуально.
Но факт в том что ветки нужны. И больше одной.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.07.2021, 19:48
    #40083889
PetroNotC Sharp
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
Stanislav Bashkyrtsev,
"
При переходе на Git вы должны привыкнуть к тому, что для того, чтобы поделиться фиксацией с коллегами, требуется три шага. В большинстве систем контроля версий есть только один шаг: передача из рабочей копии на общий сервер. В Git вы добавляете файлы из рабочей копии в область подготовки. После этого вы фиксируете их в своем локальном репозитории. Третий шаг - отправка в общий удаленный репозиторий. После того, как вы привыкнете к этим трем шагам, следующей проблемой станет модель ветвления.
"
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.07.2021, 20:25
    #40083896
PetroNotC Sharp
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
Stanislav Bashkyrtsev,

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

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

Я понимаю, что это - антипаттерн работы, но мне почему-то так удобно. Если кто знает оптимизацию или автоматизацию
подобного - сообщите plz.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.07.2021, 09:26
    #40083969
Андрей Панфилов
Андрей Панфилов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
mayton
Я понимаю, что это - антипаттерн работы, но мне почему-то так удобно. Если кто знает оптимизацию или автоматизацию
подобного - сообщите plz.
Очевидно же: нужно два разных десктопа
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.07.2021, 09:28
    #40083971
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maven и зависимость по коммиту гита
Андрей Панфилов
mayton
Я понимаю, что это - антипаттерн работы, но мне почему-то так удобно. Если кто знает оптимизацию или автоматизацию
подобного - сообщите plz.
Очевидно же: нужно два разных десктопа
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Java [игнор отключен] [закрыт для гостей] / Maven и зависимость по коммиту гита / 25 сообщений из 48, страница 1 из 2
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 836ms
Закрыть
start [/forum/topic.php?fid=59&tablet=1&tid=2120394]:
 0ms
get settings:
 7ms
get forum list:
 5ms
check forum access:
 1ms
check topic access:
 1ms
track hit:
 40ms
get topic data:
 5ms
get forum data:
 1ms
get page messages:
 424ms
get tp. blocked users:
 1ms
others: 351ms
total:  836ms
x
x
Закрыть


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