Как начать с непрерывной интеграции

Все, что вам нужно знать, чтобы начать с непрерывной интеграцией. Стратегии ветвления, автоматизация тестов, инструменты и лучшие практики.

Цель: быстро и безопасно доставить рабочий код

Цель непрерывной интеграции состоит в том, чтобы доставить код в основную ветвь вашего репозитория:

Быстро: от перемещения нового кода в репозиторий до объединения его до основной ветви, когда он работает, должно быть сделано в течение нескольких минут
Безопасно: Откуда мы знаем, что новый код работает? Непрерывная интеграция — это настройка правильных проверок для автоматического слияния кода в полной уверенности

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

Есть 2 столпа для достижения непрерывной интеграции.

Работать в маленьких кусках

Представьте себе команду из 5 человек, работающих над продуктом SaaS. Каждый из них разрабатывает отдельную новую функцию. Рабочая нагрузка на каждую функцию составляет около 1 или 2 недель. Есть 2 способа пойти сюда.

Команда может пойти с филиалами. Каждый разработчик будет работать со своей стороны с «филиала функций». Филиалы будут объединены с главной ветвью, как только все будут довольны своей работой
Команда могла бы пойти с филиалами (все еще), но интегрировать свою работу в основную ветвь на каждом толчке. Даже если все будет в процессе работы! Работа, которая будет оставаться невидимой для любого конечного пользователя или тестера основной ветви

Как вы думаете, какой подход будет работать лучше всего?

Первый подход в конечном итоге приведет к «непредсказуемому синдрому высвобождения». Давно живые филиалы функций создают ложное чувство безопасности и комфорта для каждого разработчика индивидуально Анкет Поскольку филиалы распадаются в течение длительного периода времени, нет никакого способа измерить, насколько сложно все это объединить. В лучшем случае возникнут некоторые незначительные конфликты кода, в худшем случае основные предположения дизайна будут оспариваться, и все будет переработано … трудный путь.

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

Смотрите пост о Почему вы не должны использовать филиалы функций Для грязных деталей.

Второй подход — это то, что нам нужно для обеспечения непрерывной интеграции. Каждый разработчик работает над собственной филиалом. Разница в:

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

Таким образом, команда может исправить конфликты и выравнивать предположения о дизайне быстрее и проще. 5 небольших проблем, обнаруженных на ранней стадии, намного лучше, что 1 большая проблема обнаружена незадолго до дня выпуска. Проверьте раздел «Функция переключателей» ниже, чтобы увидеть, как вы должны интегрировать «работу в прогрессе» в основную ветвь.

Безопасность поставляется с автоматическими проверками

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

Тип тестов и контент должны быть:

достаточно быстро, чтобы дать обратную связь разработчику в течение нескольких минут
достаточно тщательно, чтобы объединить код с основной ветвью в полной уверенности

К сожалению, нет единого размера, подходящего для всех тестов и контента. Правильный баланс специфичен для вашего проекта. Не запускайте большие и трудоемкие испытательные люксы во время фазы CI. Такие тесты обеспечивают лучшую безопасность, но они поставляются за счет отсроченной обратной связи для разработчиков. Это приводит к переключению контекста, что является чистой тратой времени.

Оптимизировать время разработчиков и уменьшить переключение контекста

Длинные проверки CI, и в течение долгого времени я имею в виду более 3 минут, вводите сложную трату времени для каждого разработчика в вашей команде. Давайте сравним «хороший» и «плохой» рабочий процесс. «Хороший» рабочий процесс:

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

«Плохой» рабочий процесс:

Вы совершаете и выдвигаете свой код
Сборка CI и тесты работают в течение 15 минут
Что вы делаете в течение этих 15 минут?
- Вы можете взять чашку кофе с командой. Достаточно справедливо, но сколько из них вы можете иметь в день?
- Вы, вероятно, получите свою голову на следующую задачу в вашем трубопроводе
15 минут спустя вы получите неудачное уведомление о сборке. Вам нужно вернуться на предыдущую задачу, попробуйте решить проблему … и перейти на еще 15 минут …
В этот момент вы задаетесь вопросом: должен ли я вернуться к этой следующей задаче или просто подождать 15 минут и достичь душевного спокойствия, что я действительно сделал с моей нынешней задачей …

Плохой рабочий процесс — это не только пустая трата времени. Это также разочаровывает для разработчиков. А продуктивные разработчики — счастливые разработчики.

Вам нужно выравнивать свои инструменты и рабочие процессы, чтобы ваши разработчики были счастливы.

Инструменты

Разветвление

Непрерывная интеграция — это интеграция кода из разных ветвей разработчиков в общую филиал в вашей системе управления конфигурацией. Скорее всего, вы используете git. В GIT основная ветвь по умолчанию в репозитории называется «Мастер». Некоторые команды создают филиал под названием «Разработка» в качестве основной ветви для непрерывной интеграции. Они используют «Мастер» для отслеживания доставки и развертывания (разработка объединения для мастера).

У вас, вероятно, уже есть основная филиала, к которой ваша команда подталкивает или объединяет код. Придерживаться.

Каждый разработчик должен работать над своей отделкой. Можно использовать несколько ветвей, если работают на разных темах одновременно. Хотя это было бы признаком «не сфокусированной» работы в лучшем случае. Как только будет готова к последовательной части вашего кода, нажмите свой репозиторий. CI будут проверены, и объединит ваш код в главную филиал, если они успешно. Если чеки терпят неудачу, вы все еще находитесь в своей собственной ветви и можете исправить то, что нужно, и снова нажать.

Важным словом в процессе выше это Последовательная часть вашего кода Анкет Откуда вы знаете, что это последовательно? Простой.

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

С другой стороны, если вашему сообщению в вашем коммите требуется 3 пули и много прилагательных и наречий, это, вероятно, не очень хорошо. Разделите свою работу на несколько, последовательные коммиты. А затем нажмите код. Последовательные коммиты помогают обзорам кода и облегчают историю хранилища.

Не просто толкайте все, потому что это конец дня!

Вытащить запросы

Что такое запрос на тягу? Запрос на тягу — это концепция, в которой вы просите команду объединить вашу филиал с главной филиалом. Принятие вашего запроса должно пройти статус, предоставленный вашим инструментом CI, и потенциально обзор кода. В конечном счете, ручное принятие человека, отвечающего за объединение запросов на притяжение.

Запросы на тягу родились в проектах с открытым исходным кодом. Содействия нуждались в структурированном способе оценки вкладов, прежде чем их объединить. Запросы на вытягивание не являются частью GIT. Они поддерживаются любым поставщиком GIT (Github, Bitbucket, Gitlab, …).

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

Если вы используете запросы на привлечение, применяются те же принципы или «работа в небольших кусках» и «оптимизируют время разработчиков»:

Сохраняйте каждый запрос на привлечение маленьким и с одной четкой целью (это облегчит обзор кода)
Держите свои чеки CI быстро

Автоматические проверки

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

Вдобавок к компиляции вы должны запускать автоматические тесты, чтобы обеспечить правильно работает программное обеспечение. Чем лучше тестовое покрытие, тем лучше уверенность в том, что вы можете иметь в новом коде, объединенную с основной ветвью. Осторожно! Лучшее покрытие означает больше тестов и более длительное время выполнения. Вам нужно найти правильный компромисс.

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

Если вы создаете приложение SaaS, вы должны проверить, что пользователи могут зарегистрироваться или входить в систему, и выполнять самые основные операции, которые обеспечивает ваш SaaS. Если вы не разрабатываете конкурента Salesforce, вы сможете запустить свои тесты в течение нескольких минут, если не секунды. Если вы создаете бэкэнд обработки данных: используйте ограниченные наборы данных, чтобы использовать различные строительные блоки. Продолжайте долгое время пробега на больших наборах данных из непрерывной интеграции. Долго работает тесты после объединения кода.

Pro Tips

Функции переключаются

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

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

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

Единственным недостатком функций переключается на том, что вам нужно периодически чистить их из окружающей среды и кода. Как только функция протестирована и принята пользователями, это должно быть по умолчанию. Код для переключения и старой версии вещей (если таковые имеются) должны быть очищены. Не попадайте в ловушку системы «конфигурации как переключатели». Подводная камень заключается в том, что вы никогда не сможете поддерживать и проверять всю комбинацию переключателей и в конце концов иметь хрупкую архитектуру.

Держите CI строить время до 3 минут

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

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

Используйте больше емкости. Если у вас недостаточно параллельных сборки на вашем инструменте CI и сборки сражаются в очередь, разработчики теряют время
Кэширование использования: большинство технических стеков требуют установки и настройки зависимостей при запуске новой сборки. Ваш инструмент CI должен иметь возможность кэшировать эти шаги, когда зависимости не изменяются, чтобы оптимизировать время сборки
Просмотрите свои тесты: Убедитесь, что ваши тесты оптимизированы на время. Удалите тайм -ауты и «безопасно длинные» шаги ожидания. Если у вас есть тяжелые тесты, которые можно запустить, рассмотрите возможность перемещения их на отдельную сборку, которая запускается после слияния в главную ветвь. Они больше не будут частью защиты непрерывной интеграции, но тяжелые тесты не должны быть в любом случае
Разделите базу кода: у вас должно быть все в одном хранилище? делать Вы должны строить и запускать тесты на все, даже когда какая -то небольшая часть меняется? Здесь могут быть победы.
Запустите тесты условно: запустите свои тесты только в том случае, если некоторые каталоги изменились. Если ваша кодовая база хорошо организована, это может быть огромной победой

Самое замечательное в том, что вы настаиваете на короткие сроки на ваши проверки CI, заключается в том, что это требует от вас принципиально улучшить весь процесс разработки.

Как Джим Рон сказал:

«Станьте миллионером не за миллион долларов, а за то, что он сделает с вами, чтобы достичь этого»

Виртуальное слияние: только ваш код на самом деле не имеет значения

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

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

Злой менеджер задач

Существует неверное поле, что круто иметь возможность проследить код, связанный с задачей в вашей гибкой плате или трекере для ошибок, такой как Jira или аналогичный. Хотя это хорошая концепция на бумаге, влияние на процесс разработки наверняка не стоит усилий. Менеджер задач предоставляет представление о мире «функции и ошибки». Код структурирован и слоилен совсем по -другому. Попытка примирить элемент в менеджере задач и набор коммитов бессмысленна. Если вы хотите знать, почему был написан часть кода, вы сможете получить информацию из контекста кода и комментариев.

Последние мысли

Инструменты — это только инструменты. Настройка инструментов, вероятно, 1 час. Если вы используете их неправильно, вы не получите ожидаемых результатов.

Имейте в виду цели, которые мы ставим для себя для непрерывной интеграции:

Быстро и безопасно доставить рабочий код
Оптимизировать время разработчиков и уменьшить переключение контекста

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

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

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

Несколько практических примеров:

Вы работаете над новой функцией и должны изменить компонент низкого уровня, которые другие, скорее всего, будут использовать. Сделайте выделенный коммит для этой общей части компонента и уже объедините ее. Затем продолжайте работать над остальной частью вашей функции. Другие разработчики смогут сразу основать свою работу на ваших изменениях.
Вы работаете над большой функцией, которая потребует много времени и кода? Используйте функцию переключения. Не работайте в изоляции. Всегда!
Вы ждете проверку кода, но никто не доступен для этого. Если ваш код проходит проверки CI, просто объедините его и сделайте проверку кода потом. Если это звучит как нарушение процесса, помните, что «сделано лучше, чем идеально». Если он работает, он обеспечивает большую ценность в основной филиале, чем припарковано на стороне в течение нескольких дней.

Спасибо за чтение!

Статья первоначально опубликована по адресу Fire.ci 9 апреля 2019 года.

Оригинал: «https://dev.to/jpdelimat/how-to-get-started-with-continuous-integration-1o9b»