Комментарии 14
Сейчас как раз думаю над CI. Пока что смотрю в сторону GitLab + сервисы гугла для деплоя (базы, kubernetes).
Описываемые в статье события происходили около двух лет назад (я забыл об этом упомянуть). С тех пор ландшафт слегка поменялся, многие инструменты заметно повзрослели.
Да я так и подумал. Сегодня бы как это всё делали?
Наверное, последний шаг CI pipeline, — собственно развёртывание экземпляра приложения в томкэт, — сделал бы через какую-нибудь контейнеризацию. (Докер, скорее всего. Два года назад с ним у меня ничего путного не вышло, а теперь он стал вполне юзабелен.)
И, конечно, не стал бы колхозить консольку своими силами, а заюзал штатную к данной контейнерной системе панель управления. В них и статистика по загрузке есть, и средства диагностики.
И, конечно, не стал бы колхозить консольку своими силами, а заюзал штатную к данной контейнерной системе панель управления. В них и статистика по загрузке есть, и средства диагностики.
Ох и велосипеды :) а за то, что в мастер, и не только в него, разрешен пуш с форсом надо бить по рукам, причем долго. Уже давно везде есть защита от подобного
В условиях раннего стартапа (недолго, первые месяцы) важно сохранять полное доверие внутри команды, а каждый из ранних разработчиков — на вес золота. Иначе обидься кто, и всё, стартап можно хоронить.
Это потом, когда людей становится больше, и их уже можно заменять, главными становятся правила, процессы, и всё такое. Но любые ограничения должны приниматься обоснованно и добровольно. Вся статья — по сути хроника того, как это происходило.
Это потом, когда людей становится больше, и их уже можно заменять, главными становятся правила, процессы, и всё такое. Но любые ограничения должны приниматься обоснованно и добровольно. Вся статья — по сути хроника того, как это происходило.
В условиях раннего стартапа (недолго, первые месяцы) важно сохранять полное доверие внутри команды, а каждый из ранних разработчиков — на вес золота. Иначе обидься кто, и всё, стартап можно хоронить.
тогда надо гнать такого разработчика, серьезно. Тимлид как минимум должен сам попросить поставить подобные ограничения, если у него нет таких прав. И это не ограничение, а защита команды от таких случайностей/глупостей, чтобы потом не приходилось разгребать завалы после форса.
P.S.
странно, что не посмотрели в сторону того же rundeck ибо проекту лет 5 минимум, если не больше. Думаю вписался в ваш CI идеально
Да, действительно не повезло со «временем» )
Сейчас gitlab, CI встроен, review apps на ветки, авто-дестрой при мердже. Все практически мышкой и бесплатно.
Ну и да, на стороне runner's — docker со всеми вытекающими.
p.s. консолька управления олдскульная понравилась.
Сейчас gitlab, CI встроен, review apps на ветки, авто-дестрой при мердже. Все практически мышкой и бесплатно.
Ну и да, на стороне runner's — docker со всеми вытекающими.
p.s. консолька управления олдскульная понравилась.
- разрабатываемый небольшой командой (~15 человек),
- с использованием кучи (порядка 40 штук параллельно) фич-бранчей,
Получается, в среднем каждый разработчик одновременно работает над двумя с половиной фичами? Это из-за того, что фичи какое-то время на тестировнии и ревью находятся?
Именно. Причём, фича может довольно долго тестироваться бизнесом, и по итогам быть полностью переделанной.
Ещё вариант: фича сделана, оттестирована и готова к внедрению, но бизнес отмашки не даёт по каким-то своим соображениям. Мало того, что ветка болтается, так её надо постоянно поддерживать в актуальном состоянии, чтобы после отмашки не возникло кучи конфликтов и регрессий.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выстраиваем процесс разработки и CI pipeline, или Как разработчику стать DevOps для QA