Как стать автором
Обновить

Комментарии 25

Спасибо за представление вашего варианта, но без конкретных примеров ценность материала сильно уменьшается. Попробуйте всё-таки сделать какой-то мини проект на вашей базе.
Ссылка на минипроект в конце статьи. Там две приложухи и devops.
запретили напрямую пушить в ветки master, develop и release, только через пул-реквесты;

существует мнение что это противоречит идее CI/CD. Что вы думаете по этому поводу? Я не к тому что "разрешить всем пушить в master/release", остановимся только на develop. Ограничения на остальных ветках пусть останутся для код фриза.

Как запрет напрямую пушить в ... влияет на ci/cd?

Это замедляет процесс интеграции кода, все работают с изолированными изменениями и потенциально это влияет на процесс.


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

Строго говоря запрет напрямую пушить и ci/cd друг к другу ортогональны.
В данном случае может быть ci/cd на пул-реквесты, т.е. автосборки автособираются, дают обратную связь по качеству, люди при этом оценивают код не только с точки зрения машинного качества, но и точки зрения человеческого — оформление, понятность и прочее.
Т.е. ci/cd не про запрет пушить, а про регулярную проверку качества.
Т.е. ci/cd не про запрет пушить, а про регулярную проверку качества.

Очень интересное определение, не поделитесь источником? Просто обычно когда говорят о continious integration то имеют ввиду "интеграция кода происходит хотя бы раз в день".

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

Бывает ли у вас так что пул реквест висит несколько дней?

Предположим, какой-то пул-реквест завис. Это означает, что для данного проекта ci/cd отсутствует?

Не факт конечно, уж точно ничего про CD по этому критерию мы говорить не можем. А вот CI — зависит от того как часто у вас происходят такие вот "зависания" скорее и почему они возникают.


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


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

Представьте, у вас все артефакты лежат в репозитариях, все покрыто тестами, вся инфраструктура управляется специальными cfg mgnt тулами, со всего собираются и анализируются логи, и все это завернуто в единый pipeline. И для вас ценно, что изменения не пушатся напрямую в основной код, а ревьюются человеком. Из-за этого у вас не кошерный CI/CD, а какой-то рафинированный? И кошерным он станет, тогда и только тогда, когда всем будет дадено разрешение пушить напрямую?

CI/CD — про управляемый повторяемый способ контроля качества и доставки изменений. Не про модель контроля версий.
И для вас ценно, что изменения не пушатся напрямую в основной код, а ревьюются человеком.

Если все так как вы описали — какая ценность для в том что код ревью обязательно должен происходить ДО попадания в основной код?


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

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


Я пожалуй все же поясню — суть CI — постоянная интеграция (для чего необходим автоматизированный контроль качества). С пулреквестами это организовать очень сложно, так как подразумевает короткий цикл жизни этих самых пул реквестов. Требует неплохого уровня дисциплины команды. При этом если команда уже настолько хорошо работает — почему бы не пойти дальше? Я не говорю что идти дальше надо, но почему нет?

Мы новые версии продукта начинаем из ветки develop, и очень важно, чтобы код в этой ветке не оказался бракованным из-за того, что кто-то решил сделать пуш с «безобидными» правками. Сейчас это невозможно, чтобы что-то попало в master/develop/release необходимо сделать пул-реквест с запуском Jenkins'а, даже если мы пытаемся влить уже протестированный release в develop.
и очень важно, чтобы код в этой ветке не оказался бракованным

Именно по этому CI как процесс требует наличия автоматической системы "проверки на брак". Далее опять же важный момент это код фризы (например тегами) какой-то версии для стабилизации.


необходимо сделать пул-реквест с запуском Jenkins'а

jenkins и так по пушу будет запускаться и если билд упадет — ну у вас не будет билда зато это привлечет внимание команды и возможно подстегнет анализ ситуации.


даже если мы пытаемся влить уже протестированный release в develop.

а в каких ситуациях у вас подобное может происходить? У вас часто в release напрямую попадают изменения (я так понимаю какие-то хотфиксы)?


p.s. Мне просто интересно мнение людей, ибо часто когда я общаюсь с людьми замечаю что под CI/CD имеют ввиду не процесс а инструменты.

это код фризы (например тегами) какой-то версии для стабилизации
Тэги делаем из ветки release в каждом репозитории проекта для дальнейшего интеграционного тестирования данной версии.

jenkins и так по пушу будет запускаться
Это так, но упавший билд не привлечёт внимание команды. Он виден только либо из самого Jenkins'a, либо из vcs, но заходить туда лишний раз никто не станет. На данном этапе, Jenkins запускается после пуша, т.е. изменения уже будут в develop'e, и их уже смогут себе спуллить.

а в каких ситуациях у вас подобное может происходить?
Да, это хотфиксы к текущей версии продукта, которую пытаемся сдать, а в это время в develop'е разрабатываем функционал для следующей версии. И, несмотря на то, что все хотфиксы также проходят через пул-реквесты и release тестируется, чтобы его влить в develop также делаем пул-реквест. Больше для проформы, но всё-таки.
но упавший билд не привлечёт внимание команды.

email/slack/telegram/etc или дашборд со статусом сборки. И вроде как все в курсе.


через пул-реквесты и release тестируется

а master ветка зачем? В целом можно этот вопрос по разному решать, просто мне кажется противоестественным когда код из release в develop попадает. Мы в этом случае делали просто cherry-pick коммитов. Благо штука не частая.


Из моего опыта в целом флоу работы через пул реквесты очень сильно замедляет разработку и при этом не сильно добавляет качества. Что до обмена знаниями в команде — есть и другие подходы которые намного эффективнее. Но это только если есть возможность что-то такое делать. Чаще всего просто тесты не пишут, как минимум, что уже отсекает массу вариантов для эксперементов в плане оптимизации процессов.

кажется противоестественным когда код из release в develop попадает

Это одна из классик nvie.com/posts/a-successful-git-branching-model
И это не исключает того, что могут быть и другие классические модели.
email/slack/telegram/etc или дашборд со статусом сборки
Это всё равно всё посторонние штуки, куда надо зайти и посмотреть, сами по себе они ничего не запретят. У нас настроен хук на слак, туда идут успешные и неуспешные сборки. По всем проектам по всем сборкам. Никто не смотрит.

а master ветка зачем?
Master — продакшен, release — потенциальный продакшен. Процесс у нас такой: готовим версию, например, третью, сделали, протегировали как 3.0, CI протестировал, развернули на тестинге. Тестировщики, менеджеры, в некоторых случаях и клиенты, могут зайти посмотреть что и как, если нашли дефекты — мы делаем хотфиксы в этот release, с тэгом 3.1, и т.д. В какой-то момент дефектов найти не смогут — вот этот тэг и будет сливаться в мастер и девелоп.

Чаще всего просто тесты не пишут
Это один из моментов, за которыми мы следим в пул реквестах, если есть ветка, то должны быть новые тесты.
сами по себе они ничего не запретят.

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


Master — продакшен, release — потенциальный продакшен.

понял, привык что release это самый крайний продакшен.


вот этот тэг и будет сливаться в мастер и девелоп.

до этого момента в develop эти баги все еще присутствуют? Или в целом работа над develop на это время приостанавливается?


Это один из моментов, за которыми мы следим в пул реквестах, если есть ветка, то должны быть новые тесты.

но это можно автоматизировать + подключить мутационные тесты как показатель качества юнитов (если вы пишите юниты а не только интеграционные).

Зафэйлился билд — стопорится работа всех
Не вижу смысла стопорить работу всех, и даже привлекать к этому какое-то дополнительное внимание. Фейл билда, например, release-ветки касается только людей, которые занимаются этой версией, они видят этот фейл и правят его. И вызван он кодом, который они сами и сделали. Разработчикам, которые в это время разрабатывают следующую версию продукта в develop-ветке, а по факту это просто новый функционал, который чаще всего не связан с функционалом, над которым сейчас работают в release-ветке, нет необходимости знать о фейлах в сборке release-ветки. Главное, они знают, что в итоге к ним смогут влить только «хороший» код. Для этого и нужен именно запрет.

до этого момента в develop эти баги все еще присутствуют?
Да, они присутствуют в develop'e, но это, в большинстве случаев, ни на что не влияет, от данной ветки мы хотим получить только работающий новый функционал. Проверка функционала по всему прокту происходит в ветке release. Выходит, что текущий релиз хотфиксами поправили, затем влили в девелоп, получили поправленный старый функционал плюс новый, и делаем новый release.

но это можно автоматизировать + подключить мутационные тесты как показатель качества юнитов
До этого мы ещё не дошли.
Фейл билда, например, release-ветки касается только людей, которые занимаются этой версией

Надо было пояснить кто все. Все верно, фэйл билда затрагивает только людей, которые с этими билдами работают.


Идея не в том что бы "блочить" а в том что бы тригерить общение команды. Еще из бонусов того что все работают с одним и тем же кодом — регрессии которые не выявили тесты проще находить (чем больше команда — тем проще). Но это опять же не для всех будет работать. Я же не агитирую, просто интересно мнение других.


До этого мы ещё не дошли.

просто интереса ради попробуйте мутационные тесты прогнать. Это не много времени занимает (настройка, запуск бывает весьма длительным) и дает интересную статистику по качеству тестов. Можно просто с командой раз в недельку скажем делать.

Спасибо за идеи!
— Все ли члены команды работают над всеми репозиториями? У всех ли членов команды есть доступы до всех репозиториев?
— Кто заводит ветки в репозиториях? один член команды во всех репах по задаче или же по одной задаче каждый отвечающий за конкретный реп?
— Чья обязанность влить все в версию? Как убедиться, что все ветки всех репозиториев были слиты\приняты по данной версии?

Все ли члены команды работают над всеми репозиториями?
Нет, только разработчики, работающие над конкретной версией проекта.
У всех ли членов команды есть доступы до всех репозиториев?
Права на чтение есть у всех разработчиков, права на запись делятся в зависимости от бэк/фронт репозиториев. Админские права есть у разработчика, отвечающего за данную версию.
Кто заводит ветки в репозиториях?
Ветки может заводить любой разработчик, одна задача — одна ветка.
Чья обязанность влить все в версию? Как убедиться, что все ветки всех репозиториев были слиты\приняты по данной версии?
За это отвечает ответственный за данную версию разработчик.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории