Непрерывная Интеграция — Должен Ли Разработчик Ждать Завершения Конвейера Ci Или Начать Следующую Задачу После Отправки

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

В настоящее время наш конвейер CI включает в себя создание проекта и статический анализ кода, чтобы убедиться, что он соответствует нашим стандартам кодирования. Далее мы будем проводить тестирование. Сборка и статический анализ кода сейчас занимают около 3 минут. Судя по тому, что я читал, немедленное устранение проблем имеет решающее значение для CI/CD. Я ожидаю, что когда мы добавим модульные тесты, запуск конвейера может занять около 10 минут.

Итак, мой вопрос: когда разработчик делает запрос на вытягивание/слияние, должен ли он дождаться завершения конвейера CI или просто перейти к следующей задаче и вернуться, чтобы исправить проблемы конвейера, если они существуют? Или им следует сидеть и смотреть, как работает трубопровод?

#непрерывная-интеграция #git #непрерывная-доставка

Сидеть и смотреть, как работает трубопровод?

Нет, это не то, как вы работаете эффективно.

Разработчики отправляют свои коммиты в репозиторий системы контроля версий, после чего запускается конвейер CI/CD.

Разработчики могут опубликовать хорошо написанный запрос на включение в любое время. Обычно имеется визуальный знак, обозначающий «текущую сборку»/«неудачную сборку»/«успешную сборку».

Обычно ветка может быть объединена в любое время. все этим критериям соответствует:

• по крайней мере один утверждающий / или столько, сколько необходимо для утверждения, одобрили.
• «успешная сборка»
• нет неразрешенных конфликтов слияния

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

Я рекомендую приложить все усилия, чтобы время конвейера составляло менее 10 минут. Для этого вы можете выполнять тесты параллельно.

Как ответил Джонас, они могут затем потратить время на создание запроса на извлечение (пока конвейер работает).

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

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

Хорошо, давайте предположим, что у вас есть инструмент контроля версий, такой как Git, и инструмент CI Jenkins.

1. Итак, Дев создает ветку функций для проблемы. В вашем инструменте CI есть многоветвевой конвейер или рабочий процесс, который обнаруживает эту ветвь функции при следующем сканировании и выполняет шаги CI.

2. Итак, необходимо обеспечить следующее:

3. До повышения PR/MR задание CI имеет зеленый цвет. Если он не зеленый, PR/MR не следует повышать. Очевидно, что разработчик может выполнить другие задачи, а затем вернуться и исправить проблему в этой задаче, это его выбор в зависимости от приоритета задачи. Вы даже можете контролировать повышение PR, проверяя его параметры CI. (Если вы не слишком доверяете своему разработчику, и они постоянно повышают PR за неработающие сборки)

Как только будет поднят PR, рецензент кода проверит и объединит код, если все в порядке. Рецензентом кода может быть любой другой разработчик. Его/ее обязанность — просмотреть код и убедиться, что он соответствует критериям «Определение готовности». DoD — это в основном термин Agile, но Agile и DevOps идут рука об руку.