CI/CD, стратегии ветвления Git и варианты деплоя

Смысл доставки кода

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

Зачем нужен CI/CD

CI/CD — это специальная штука, которая закрывает путь от разработки до продакшна. В типичном процессе есть среда разработки, затем сборка артефакта, затем его тестирование на разных этапах и стендах, и только после этого — попадание в production. Именно этот конвейер и автоматизирует CI/CD.

Как было раньше

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

Ручной процесс и его проблемы

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

Что меняет CI/CD

Появление CI/CD сделало процесс заметно проще: сборка, тестирование и доставка стали повторяемыми и автоматизированными. Благодаря этому уменьшается число ошибок до попадания на Prod, повышается качество кода и растет скорость релизов. Вместо постоянной ручной рутины появляется воспроизводимый процесс, где артефакт проходит через заранее заданные стадии и стенды.

Continuous Integration

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

Continuous Delivery и Continuous Deployment

CD в CI/CD может означать либо Continuous Delivery, либо Continuous Deployment, и это разные вещи. Continuous Delivery — это когда весь путь автоматизирован почти до конца, но последний шаг на production остается ручным: человек нажимает кнопку деплоя, когда все готово. Continuous Deployment — это уже полностью автоматическая доставка, включая выкладку в прод.

Почему delivery и deployment не одно и то же

В Continuous Delivery мы автоматизируем все, что можно, до самого последнего этапа. Идея в том, что релиз должен быть готов, проверен и только потом вручную разрешен к попаданию в production. В Continuous Deployment этот барьер снимается, поэтому релиз уходит в прод без ручного подтверждения.

Ограничения полной автоматизации

Чем система крупнее и критичнее, тем менее реалистичен Continuous Deployment. Для business-critical систем полная автоматизация выкладки опасна: при ошибке ущерб будет слишком большим. Поэтому полностью автоматическая доставка уместнее в небольших, менее критичных проектах, где сбой быстро чинится.

Что дает CI/CD на практике

Главная польза CI/CD в том, что большая часть работы автоматизирована, а артефакт проходит через разные стенды — production и его копии. Это позволяет ловить ошибки раньше, чем они попадут к пользователям, и менять количество, тип и конфигурацию стендов гибко под задачу. Автоматизация ускоряет процесс и делает его более предсказуемым.

Типичный CI/CD-пайплайн

На практике CI/CD выглядит как последовательность этапов: код коммитится, затем начинается build, дальше прогоняются unit-тесты, интеграционные тесты и дополнительные проверки. После завершения CI начинается CD: артефакт деплоится на stage и затем в другие среды, включая production.

Пример из GitLab

Лектор приводит схему из GitLab: сначала что-то протестировали, потом собрали, затем задеплоили в dev, потом снова собрали и задеплоили в prod. Отдельно могут быть job’ы для мониторинга и настройки. Это очень упрощенный, но показательный вариант того, как CI/CD реализуется в реальных системах.

Стенды и повторяемость

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

Почему это удобно

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

Реальные сложности

В реальности CI/CD может быть сильно усложнен множеством нюансов: параметризацией, большим числом сред, дополнительными проверками и ручными исключениями. Лектор шутливо показывает и «идеальный» путь, и хаотичный процесс с ручными правками на стенде, которые забыли закоммитить. Этот пример подчеркивает, зачем нужны автоматизация и дисциплина в пайплайне.

Почему CI/CD связан с Git

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

Стратегия ветвления как часть процесса доставки

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

Коммиты и их качество

Лектор приводит негативный пример: пушить все в один main — плохая практика для нормальной командной среды, хотя для pet project это допустимо. Также он рассказывает про слишком большие коммиты: один длинный коммит на русском с огромным текстом в message плохо читается и плохо откатывается. Лучше делать частые и мелкие коммиты.

Хорошие практики в Git

Рекомендуется использовать naming convention для коммитов, Gitignore для исключения лишних файлов и секретов, а также code review. Важна и привычка делать rebase, если рабочая ветка отстала от основной: перед merge нужно привести ее к актуальному состоянию. Это уменьшает конфликты и делает историю чище.

Зачем это нужно в CI/CD

Все эти практики важны потому, что в CI/CD особенно критично уметь быстро и надежно откатывать состояние обратно. Чем более аккуратна история коммитов и ветвлений, тем проще поддерживать стабильность релизов, сравнивать изменения и находить источник проблем.

One Branch Flow

Самая простая стратегия — One Branch Flow. Лектор описывает ее как случай pet project или небольшого личного бота, где можно работать прямо в одной ветке, например в master, и не заботиться о чистоте истории. Это простое решение, когда сложная организация веток просто не нужна.

Git Flow

Git Flow — одно из самых популярных решений, но лектор относится к нему сдержанно из-за сложности и медлительности. Основная ветка main хранит максимально стабильный код и почти не используется в активной разработке. Основная работа идет в develop, от которого отводятся feature-ветки для конкретных задач.

Релизы и hotfix в Git Flow

Когда develop достаточно стабилен, от него отводится release-ветка. Она вливается в main, после чего из main раскатывается production. Если нужно срочно исправить маленькую проблему, используется hotfix: ветка отводится прямо от main, вносится микроправка, и затем она сразу вмерживается обратно. Это удобно, когда нужно быстро поменять одну переменную или отключить проблемную фичу.

GitHub Flow

GitHub Flow проще: есть основная ветка main и feature-ветки. Разработчик создает фичу, реализует ее в отдельной ветке и потом вмерживает обратно. Лектор считает этот вариант самым простым и элегантным, особенно если хочется стартовать с минимальной сложности.

GitLab Flow

GitLab Flow — промежуточный вариант между Git Flow и GitHub Flow. Есть main с актуальным кодом, затем перед релизом отводится отдельная release-ветка, после чего возможна еще одна стадия — production-ветка. Ветки для релиза сохраняются как отдельные сущности, и к ним можно вернуться, чтобы посмотреть, что именно было в конкретном релизе.

Идея trunk-based development

Trunk-based development — любимая стратегия лектора, но не все команды могут ее себе позволить. Смысл в том, что есть одна главная ветка, обычно не совсем main, а какая-то основная trunk-ветка, и разработка ведется прямо в ней. При этом допускаются только очень короткоживущие feature-ветки для мелких изменений.

Чем trunk-based отличается от других подходов

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

Feature flags как компенсация

Чтобы trunk-based работал, часто нужны feature flags, то есть флаги включения функций. Они позволяют держать в коде новую функциональность, но включать и выключать ее по необходимости. Это дает возможность быстро тестировать код без постоянного разветвления истории.

Практика в командах

Лектор приводит примеры: фронтендеры иногда используют trunk-based, но создают релизные ветки с номерами, например release 100, release 101 и так далее. По сути это одна длинная ветка, просто с формальным переименованием релизов. Бэкендеры чаще придерживаются develop и релизных веток. Выбор стратегии часто зависит от договоренности с ops-командой и того, какие процессы уже подстроены под GitOps.

Fork-in-flow

Fork-in-flow — это, по сути, модель работы в GitHub для публичных open source-репозиториев. Если проект чужой и публичный, нельзя просто взять ветку в том же репозитории и отправить merge request; обычно нужно форкнуть репозиторий и отправить pull request между двумя репозиториями. Это отдельная форма организации вклада в код.

Что такое deployment strategy

Лектор подчеркивает, что CI/CD — это только пайплайн, конвейер доставки артефактов, но сами подходы к выкладке тоже важны. Как и с Git, где есть стратегия ветвления, здесь есть стратегия деплоя. Именно она помогает уменьшать простои и управлять рисками при выпуске версии.

Простой deploy и частичное обновление

Самый простой deploy — это обычное обновление всех сервисов примерно одновременно, как раньше до CI/CD. Это быстро, но рискованно: либо все взлетело, либо не взлетело, и откатывать не всегда удобно. Частичное обновление лучше: сначала обновить один сервис, потом другой, особенно если между ними есть зависимости, как в примере с Airflow и Spark.

Blue-Green Deploy

Blue-Green Deploy использует две идентичные среды, между которыми можно переключать трафик. Одна среда простаивает, вторая обслуживает пользователей; новую версию сначала разворачивают на простаивающем плече, проверяют и затем резко переводят на него весь трафик. Это удобно, быстро и хорошо тестируется.

Ограничения Blue-Green

Главный минус Blue-Green — стоимость: нужно держать две полноценные копии прода, и одна из них все время простаивает. Кроме того, переключение трафика, хотя и быстрое, не мгновенное. Если в момент переключения выполняется тяжелый запрос, он может быть затронут.

Canary Deploy

Canary Deploy не требует отдельного полноценного плеча: достаточно поднять вторую версию сервиса рядом и постепенно переводить на нее трафик. Например, можно сначала отправить 25% пользователей на новую версию и 75% оставить на старой, потом постепенно увеличивать долю новой версии. Это дешевле, чем Blue-Green, быстрее откатывается и тестируется на реальных пользователях, но в малом объеме.

Сложность Canary

Минус Canary — сложность реализации. Система деплоя должна уметь перераспределять трафик и работать с несколькими копиями сервиса. Лектор приводит пример с Docker Compose и репликами: можно поднять сервис в нескольких экземплярах и направлять часть запросов на новую версию, а часть — на старую. Это уже почти искусственно созданный canary-режим.

A/B-тестирование

A/B-тестирование по смыслу похоже на Canary, но больше относится к уровню бизнеса и экспериментов с фичами, чем к чисто техническому деплою. Здесь обе версии или обе ноды могут работать одновременно, а пользователи попадают на разные варианты. Разница с Canary в том, что здесь важен именно эксперимент над функциональностью.

Что проверяют в A/B

Лектор приводит пример с включением TLS на Postgres: на одном этапе проверяют, умеют ли сервисы работать через защищенный канал. Другой пример — включение фичи в приложении и наблюдение, пользуются ли ей вообще. Если фича не нужна, ее можно убрать и больше не использовать.

Feature flags

Feature flags — более точечный вариант той же идеи. Если нет возможности держать две копии сервиса или отдельные плечи, можно выкатывать один и тот же код, но управлять поведением через флаг внутри приложения. Например, интеграция с RabbitMQ может быть выключена по умолчанию и включена уже на проде.

Rolling update

Rolling update — постепенное обновление реплик, типичное для Kubernetes. Если сервис состоит из трех реплик, одна обновляется первой, две остаются старые; затем обновляется вторая, потом третья. Трафик при этом не переводится на новые реплики, пока весь набор не будет обновлен, а проверка состояния выполняется через health checks и probes.

Стейтлесс и риски

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

Вопрос про выбор стратегии ветвления

На вопрос о том, какую стратегию ветвления стоит использовать в рабочих проектах с нуля, лектор отвечает, что GitHub Flow выглядит самым простым и практичным вариантом. В нем есть основная ветка, feature-ветки и простой merge обратно. Такой подход легче внедрить и потом при необходимости перейти на более сложные схемы.

Уточнение про Blue-Green

На вопрос о разнице между «плечом» в Blue-Green и просто отдельным инстансом лектор поясняет: в Blue-Green речь обычно идет о полноценной копии стенда, а не только одного сервиса. Если сильно упрощать, это почти два кубера с собственными балансировщиками, между которыми можно переключать трафик пользователей. Отдельный инстанс — это более локальная сущность.

Уточнение про балансировку

На вопрос о Docker Compose и репликах лектор подтверждает, что встроенный балансировщик там уже есть и может распределять трафик между репликами. При этом ничто не мешает использовать внешний балансировщик, например HAProxy. То есть способ распределения трафика можно реализовать как встроенными, так и внешними средствами.

Практический смысл A/B, feature flags и rolling update

Лектор еще раз связывает эти подходы с практикой: A/B и feature flags полезны для экспериментирования с фичами, а rolling update — для постепенной выкладки версий с проверкой готовности через пробы. На вопрос о том, что будет, если одна реплика в rolling update уже обслуживает трафик и падает под нагрузкой, объясняется, что обычно это решается оркестрацией и graceful shutdown, но теоретический риск есть.

Итог лекции

В конце лекции преподаватель подводит итог: были разобраны CI/CD, Git-ветвление и основные варианты деплоймента. Следующее занятие пропускается и будет наверстано позже, а далее тема продолжится уже на примерах в GitLab и в контексте лабораторной работы. Он также напоминает про перенос занятия и завершает лекцию.