CI / CD.

Непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) представляют собой культуру, набор принципов и практик, которые позволяют разработчикам чаще и надежнее развертывать изменения программного обеспечения.

CI / CD — это одна из DevOps-практик. Она также относится и к agile-практикам: автоматизация развертывания позволяет разработчикам сосредоточиться на реализации бизнес-требований, на качестве кода и безопасности.

Непрерывная интеграция и непрерывная поставка нуждаются в непрерывном тестировании, поскольку конечная цель — разработка качественных приложений. Непрерывное тестирование часто реализуется в виде набора различных автоматизированных тестов (регрессионных, производительности и других), которые выполняются в CI / CD-конвейере.

Цели CI / CD.

Обеспечение последовательного и автоматизированного способа сборки, упаковки и тестирования.
Автоматизация развёртывания в разных окружениях.
Сведение к минимуму ошибок и проблем.

Добиться этих целей помогают четыре принципа, на которых основана концепция CI/CD.

Первый принцип.

Разделение активности. Каждый из участников процесса делит ответственность за жизненные циклы продукта. Проектируется бизнес-логика, выбираются сквозные функции, проводятся тесты, организуется доставка кода из одного окружения в другое.

Второй принцип.

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

Третий принцип.

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

Четвертый принцип.

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

Как и у любой методологии, у CI / CD есть свои плюсы и минусы:

Плюсы.

Минимальное время от запроса клиента до запуска в использование — мы быстрее доставляем новые фичи.
Возможность проверки вариантов — можем моментально проверять изменения и при необходимости откатывать назад.
Качество результата — можем быстро обнаружить и пофиксить ошибки.

Минусы.

Сложность обеспечения взаимодействия — и DevOps-инженеры, и разработчики должны понимать, что было сделано и зачем.
Требования к опыту — нужен опыт настройки CI/CD, который почти всегда добывается с болью.

Непрерывная интеграция.

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

Непрерывная поставка.

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

Непрерывное тестирование.

Это больше, чем автоматизация тестирования. Фреймворки для автоматизированного тестирования помогают QA-инженерам разрабатывать, запускать и автоматизировать различные виды тестов, которые помогают разработчикам отслеживать успешность сборки. Тестирование включает в себя функциональные тесты, разрабатываемые в конце каждого спринта и объединяемые в регрессионные тесты для всего приложения.

Feature flag.

Многие используют фича-флаги (ручка) — механизм для включения и выключения функционала в рантайме. Функционал, который еще находится в стадии разработки, оборачивается
фича-флагами и развертывается из master-ветки в продакшн, но отключается до тех пор, пока не будет полностью готов к использованию.

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