Как собрать все мерж реквесты с тегом в дженкинс?

Question

[skorpix]

Хочу сделать, чтобы собирался образ для тестового контура.
Порядок вижу такой:
1) В дженкинсе собираем все мерж-реквесты по определенному тегу (например, deploy_test_label)
2) Мержим все ветки из МР в какую-то одну (например, deploy_test_branch)
3) По этому коду прогоняем тесты, собираем образ

У меня есть некоторые идеи
1) В дженкинсе в build-секции дергаем АПИ гитлаба Гитлаб АПИ по МР
2) Там же парсим ответ, достаем ветки и делаем git merge,

Но вот как это реализовать, я не совсем понимаю.
Плюс, неужели никто не делал такого до меня? Гуглом пользовался. но, возможно неправильно)

Answer 1

[Иван Шумов]

Так делать нельзя в принципе в концепции ci все процессы запускаются либо при появлении MR либо при его аппруве. Если в репе больше одного открытого MR - пора бежать бить тревогу

Comments

[skorpix]

Если в репе больше одного открытого MR - пора бежать бить тревогу

Не понимаю, как это работает при 2+ разработчиках.
2 разработчика делают две задачи, никак между собой не связанные. Оба в один момент времени сделали Мерж-реквест и хотят это проверить на контуре, приближенном к боевому (/ отдать тестировщикам, /пройтись Я.Танком по ручкам и т.п. - причин множество).
И как им тестить? По очереди - это ж бред. Для каждого разраба свой тестовый контур - неправильно, он должен быть приближен к боевому, а это у же дев-машина получается, да и тестировщикам неудобно. Вначале вмержить в мастер все - а если баги, так и делать ветки по починкам?

Вобщем, для меня ваша фраза звучит нелогично.

[Иван Шумов]

skorpix, а понимать надо. Мы прекрасно знаем что тестирование есть 2 видов: ручное и автоматизированное. автотест прогоняются, как правило, довольно быстро и их можно включать вообще в любой кормит для быстрой обратной связи, тут ок, как команда решит. а вот когда мы доходим до ручного или UI тестирования то начинается настоящая боль. Разработчики пилят фичи быстрее чем тестеры проверяют функциональность (как правило, но бывают исключения) и если держать большое число открытых MR то у разрабов появляется процесс блокировки изменений, который надо как-то поддерживать и это, если быть до конца откровенными, невозможно.

Как это решается? Просто. Мы вспоминаем как минимум про ветки development и master. Вспоминаем о том что есть, если надо, теги. Ну и вспоминаем что все автоматизировать не надо. Разработчики по ci постоянно мерещатся в девелоп по итогу реализации каждой фичи. Фича тестируется автоматически если такие тесты пишутся (по сути 99% это регрессия). Далее тестер подключается к тестированию определенного среза (по тегу или коммиту)

В мастер все мерджи только на ручном приводе. Деплой на прод только по MR в мастер (и по расписанию)

А теперь давайте про окружения.

Если нам надо повторяемость то надо (в идеале) на сегодняшний момент либо иметь клауд с автопровижинингом аккаунтов, либо хотябы k8s/swarm/openshift. Тестирование на одном окружении бесполезно чуть менее чем полностью по тому что чем дольше существует окружение тем больше вероятности что что-то упущено. В больших системах вообще есть требование по расписанию частичное уничтожение и. перезапуск с нуля даже production окружений.

В общем, если подытожить - не блокируйте девелоперов не оттестированными MR'ами и давайте всем чистые изолированные окружения

[skorpix]

Иван Шумов, Буду признателен, если разъясните мне один момент.
Про дев-ветку я понял, это нормальная практика.
Здесь больше вопрос в следующем:
Возьме ситуацию, приближенную к моей: делаем АПИ.
1) Разработчик пилит фичу, делает МР
2) Проходят автотесты.
3) На данном шаге ручка работает, все ок, но ее никуда не выкатывали.
4) Делается Код-ревью
5) Мержится в девелоп
6) Выкатывается в окружение для тестирования.
7) Находится косяк при выкатке/выполнении кода (забыли протестить какую-то исключительную ситацию)
8) Создается новая ветка с фиксом, переходим на шаг 1.
9) Все хорошо, все везде работает, но кол-во коммитов по одной задаче в девелоп-ветке больше, чем один, что засоряет историю.

В данном алгоритме как раз не хватает выкатки этой ветки куда-нибудь для теста всяких ситуаций.

Возможно, я неправильно вас понял и привел неверный алгоритм.
Буду рад, если вы меня поправите и/или покажете свой алгоритм работы в таких ситациях.
(Только не говорите, что это все должно быть покрыто тестами и таких ошибок быть не должно - такое всегда есть и будет).

Я работал с таким процессом:
1) Пилим МР в девелоп ветку.
2) Проходят автотесты
3) Присваиваю МР тег deploy_test
4) Запускаю сборку тестового окружения.
5) Сборка ищет все МР с данным тегом и у которых автотесты выполнены и как-то мержит их с девелопом. Если мерж не может быть автоматически, да, деплой отклоняется и разрабы должны договориться между собой и ктото снять метку, но такие ситации у нас были нечасто)
6) Все эти ветки заливаются в тест, разрабы могут проверять успешность выкатки и сами подергать ручки для проверки на различных объектах
7) Код-ревью
8) Мерж в девелоп

Да, здесь также могут быть косяки что когда тестер дойдет до исключения, придется пилить фикс-МР, но это опять же, гораздо реже, чем вообще без выкатки. Я, например, часто сталкивался с ситуацией, когда просто не покрываешь тестами то, что некоторые поля из БД/АПИ могут отсутствовать в ответе и, когда выкатываешь на тест, тебе приходят такие данные и код падает.

Подытожив, меня интересует момент, как можно в МР проверить код на выкатку и так, чтобы другие разрабы не теряли свой код.

[Иван Шумов]

skorpix,

9) Все хорошо, все везде работает, но кол-во коммитов по одной задаче в девелоп-ветке больше, чем один, что засоряет историю.

Да вообще фиолетово на самом деле. develop не обязан быть атомарным. А вот мастер - обязан и там мы используем git squash

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

Даже не собираюсь!) На самом деле я приверженец того чтобы тестирования было минимум ибо это достаточно дорого, а правильный подход к проектированию систем приводит к тому что 70-80% в принципе не имеют смысла

3) Присваиваю МР тег deploy_test

не помню чтобы можно было переприсваивать тег, но это детали уже

5) Сборка ищет все МР с данным тегом и у которых автотесты выполнены и как-то мержит их с девелопом. Если мерж не может быть автоматически, да, деплой отклоняется и разрабы должны договориться между собой и ктото снять метку, но такие ситации у нас были нечасто)

ни в коем случае. MR принимается ТОЛЬКО человеком и ТОЛЬКО после code review

6) Все эти ветки заливаются в тест, разрабы могут проверять успешность выкатки и сами подергать ручки для проверки на различных объектах

если делается API то нафиг это все не надо. Пусть тыкают либо тестеры в smoke тестировании (приемочное если память не изменяет) уже через основной ui, либо смысла сколько?

7) Код-ревью

поздно на этом шаге делать ревью. Тестерам код до. ревью попадать не имеет права

8) Мерж в девелоп

поздно. Тестерам код до девелопа отправлять не имеет смысла. Как они проверят что с остальными фичами ничего не конфликтует?

Подытожив, меня интересует момент, как можно в МР проверить код на выкатку и так, чтобы другие разрабы не теряли свой код.

не путать кислое с длинным. В MR имеет смысл только проверять автотесты и Quality Gates по оформлению. кода/его слоджности. Ну и другие разрабы не потеряют свой код если нет конфликтов. Не забываем что тут нет понятия "свой код". Один проект это коллективная ответственность команды

Answer 2

[Saboteur]

Неправильный подход.
Если это мерж-реквест в один и тот же релиз, то несвязанные друг с другом вещи и не должны вызывать никаких конфликтов в тестировании.
Если же возникают, то они должны пилиться в одну и ту же фича-бренчу.

То, что вы пытаетесь исправить - это баги интеграционного тестирования. Оно исправляется банально тем, что тот кто свой мерж реквест отправил вторым и словил багу - будет разбираться.
Просто на практике, такая ситуация встречается крайне редко при нормальной архитектуре приложения, а поэтому менять весь CI процесс в угоду именно этой фичи и вопреки нормальному git-flow по фичам - это неправильно.