Выстраиваем процесс разработки и CI pipeline, или Как разработчику стать DevOps для QA

[@Caravus]

Сейчас как раз думаю над CI. Пока что смотрю в сторону GitLab + сервисы гугла для деплоя (базы, kubernetes).

[@PastorGL]

Описываемые в статье события происходили около двух лет назад (я забыл об этом упомянуть). С тех пор ландшафт слегка поменялся, многие инструменты заметно повзрослели.

[@Caravus]

Да я так и подумал. Сегодня бы как это всё делали?

[@PastorGL]

Наверное, последний шаг CI pipeline, — собственно развёртывание экземпляра приложения в томкэт, — сделал бы через какую-нибудь контейнеризацию. (Докер, скорее всего. Два года назад с ним у меня ничего путного не вышло, а теперь он стал вполне юзабелен.)

И, конечно, не стал бы колхозить консольку своими силами, а заюзал штатную к данной контейнерной системе панель управления. В них и статистика по загрузке есть, и средства диагностики.

[@rusnow]

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

[@ALexhha]

Ох и велосипеды :) а за то, что в мастер, и не только в него, разрешен пуш с форсом надо бить по рукам, причем долго. Уже давно везде есть защита от подобного

[@PastorGL]

В условиях раннего стартапа (недолго, первые месяцы) важно сохранять полное доверие внутри команды, а каждый из ранних разработчиков — на вес золота. Иначе обидься кто, и всё, стартап можно хоронить.

Это потом, когда людей становится больше, и их уже можно заменять, главными становятся правила, процессы, и всё такое. Но любые ограничения должны приниматься обоснованно и добровольно. Вся статья — по сути хроника того, как это происходило.

[@ALexhha]

В условиях раннего стартапа (недолго, первые месяцы) важно сохранять полное доверие внутри команды, а каждый из ранних разработчиков — на вес золота. Иначе обидься кто, и всё, стартап можно хоронить.

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

P.S.
странно, что не посмотрели в сторону того же rundeck ибо проекту лет 5 минимум, если не больше. Думаю вписался в ваш CI идеально

[@wnt_brian]

Да, действительно не повезло со «временем» )
Сейчас gitlab, CI встроен, review apps на ветки, авто-дестрой при мердже. Все практически мышкой и бесплатно.
Ну и да, на стороне runner's — docker со всеми вытекающими.
p.s. консолька управления олдскульная понравилась.

[@nick_volynkin]

1. разрабатываемый небольшой командой (~15 человек),
2. с использованием кучи (порядка 40 штук параллельно) фич-бранчей,

Получается, в среднем каждый разработчик одновременно работает над двумя с половиной фичами? Это из-за того, что фичи какое-то время на тестировнии и ревью находятся?

[@PastorGL]

Именно. Причём, фича может довольно долго тестироваться бизнесом, и по итогам быть полностью переделанной.

[@VolCh]

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

[@PastorGL]

А-а-а-а! Пуд соли на раны! :)
Рекорд такой болтающейся ветки — 9 месяцев. Шутили потом соответствующе.

[@nick_volynkin]

Охохо, тоже встречался с такими ветками, написанными «в стол». Кошмар и разработчика, и тестировщика.