Комментарии 25
запретили напрямую пушить в ветки master, develop и release, только через пул-реквесты;
существует мнение что это противоречит идее CI/CD. Что вы думаете по этому поводу? Я не к тому что "разрешить всем пушить в master/release", остановимся только на develop. Ограничения на остальных ветках пусть останутся для код фриза.
Это замедляет процесс интеграции кода, все работают с изолированными изменениями и потенциально это влияет на процесс.
С гитфлоу говорить о CI можно пожалуй когда у вас дробление задач происходит на таком уровне, что позволяет хотя бы раз в день или два вмердживать изменения. Но это весьма сложно и создает немало оверхэда.
В данном случае может быть ci/cd на пул-реквесты, т.е. автосборки автособираются, дают обратную связь по качеству, люди при этом оценивают код не только с точки зрения машинного качества, но и точки зрения человеческого — оформление, понятность и прочее.
Т.е. ci/cd не про запрет пушить, а про регулярную проверку качества.
Т.е. ci/cd не про запрет пушить, а про регулярную проверку качества.
Очень интересное определение, не поделитесь источником? Просто обычно когда говорят о continious integration то имеют ввиду "интеграция кода происходит хотя бы раз в день".
Все-равно это не про запрет пушить напрямую.
Все-равно это не про запрет пушить напрямую.
Бывает ли у вас так что пул реквест висит несколько дней?
Не факт конечно, уж точно ничего про CD по этому критерию мы говорить не можем. А вот CI — зависит от того как часто у вас происходят такие вот "зависания" скорее и почему они возникают.
В целом если мы можем нажать "Merge" в любой момент времени — это ближе к CI. То есть проверка качества тут важно, дабы быть уверенным что все будет хорошо, но это не цель а средство достижения цели. Цель по сути то в том, что бы команда всегда знала что происходит и усилить коммуникацию.
Если у вас те же цели достигаются при вашем варианте процесса — ну чтож, хорошо. В большинстве случаев это не так. Ну и не CI единым. Это далеко не для всех команд будет работать. Да и говорить "у нас нет CI" в целом смысла тоже нет, подумаю что "нет CI сервера".
CI/CD — про управляемый повторяемый способ контроля качества и доставки изменений. Не про модель контроля версий.
И для вас ценно, что изменения не пушатся напрямую в основной код, а ревьюются человеком.
Если все так как вы описали — какая ценность для в том что код ревью обязательно должен происходить ДО попадания в основной код?
И кошерным он станет, тогда и только тогда, когда всем будет дадено разрешение пушить напрямую?
нет конечно, но это означает что у вас очень хорошо поставлен процесс ревью и тестирования, который позволяет пул реквестам жить пару дней перед тем как быть влитым/закрытым.
Я пожалуй все же поясню — суть CI — постоянная интеграция (для чего необходим автоматизированный контроль качества). С пулреквестами это организовать очень сложно, так как подразумевает короткий цикл жизни этих самых пул реквестов. Требует неплохого уровня дисциплины команды. При этом если команда уже настолько хорошо работает — почему бы не пойти дальше? Я не говорю что идти дальше надо, но почему нет?
и очень важно, чтобы код в этой ветке не оказался бракованным
Именно по этому 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-ветки касается только людей, которые занимаются этой версией
Надо было пояснить кто все. Все верно, фэйл билда затрагивает только людей, которые с этими билдами работают.
Идея не в том что бы "блочить" а в том что бы тригерить общение команды. Еще из бонусов того что все работают с одним и тем же кодом — регрессии которые не выявили тесты проще находить (чем больше команда — тем проще). Но это опять же не для всех будет работать. Я же не агитирую, просто интересно мнение других.
До этого мы ещё не дошли.
просто интереса ради попробуйте мутационные тесты прогнать. Это не много времени занимает (настройка, запуск бывает весьма длительным) и дает интересную статистику по качеству тестов. Можно просто с командой раз в недельку скажем делать.
— Кто заводит ветки в репозиториях? один член команды во всех репах по задаче или же по одной задаче каждый отвечающий за конкретный реп?
— Чья обязанность влить все в версию? Как убедиться, что все ветки всех репозиториев были слиты\приняты по данной версии?
Все ли члены команды работают над всеми репозиториями?Нет, только разработчики, работающие над конкретной версией проекта.
У всех ли членов команды есть доступы до всех репозиториев?Права на чтение есть у всех разработчиков, права на запись делятся в зависимости от бэк/фронт репозиториев. Админские права есть у разработчика, отвечающего за данную версию.
Кто заводит ветки в репозиториях?Ветки может заводить любой разработчик, одна задача — одна ветка.
Чья обязанность влить все в версию? Как убедиться, что все ветки всех репозиториев были слиты\приняты по данной версии?За это отвечает ответственный за данную версию разработчик.
Как мы настраивали процесс CI/CD для наших SOA-проектов