Краткое содержание
Лекция посвящена доставке кода в продакшн через CI/CD и связанным с этим практикам работы с Git. Лектор объясняет разницу между Continuous Integration, Continuous Delivery и Continuous Deployment, а также показывает, как эти подходы влияют на сборку, тестирование и выкладку артефактов. Отдельный большой блок посвящён стратегиям ветвления в Git: GitFlow, GitHub Flow, GitLab Flow, trunk-based и fork-based workflow. В конце разбираются стратегии деплоя — простой, Blue-Green, Canary, feature flags и rolling update — с их плюсами, минусами и сценариями применения.
Главы
Введение в CI/CD и зачем он нужен
00:08 — 05:00Лектор вводит тему доставки кода в продакшн и объясняет, что CI/CD нужен для автоматизации пути от разработки до выкладки. Поясняется, как раньше релиз был долгим, ручным и рискованным процессом с простоями и высоким шансом ошибки. Затем формулируется, что CI/CD повышает скорость, повторяемость и качество за счёт автоматизированных сборок и тестов.
CI, CD и различие между Delivery и Deployment
05:00 — 11:40Разбирается расшифровка CI/CD и смысл каждой части: Continuous Integration отвечает за сборку и первичное тестирование, а CD — за доставку артефакта дальше по средам. Лектор отдельно подчёркивает разницу между Continuous Delivery и Continuous Deployment: в первом случае финальный деплой на продакшн ручной, во втором — автоматический. Также объясняется, почему в критичных системах автоматический деплой на прод используется осторожно.
Пайплайны, тесты и примеры CI/CD-схем
11:40 — 18:20На примерах GitLab и типовых схем показывается, как выглядит пайплайн: коммит, сборка, юнит- и интеграционные тесты, стейджинг и выкладка в продакшн. Лектор отмечает, что pipeline — это цепочка автоматических действий, а тестирование может выполняться на разных этапах. В качестве иллюстрации приводятся и простые, и чрезмерно сложные реальные схемы CI/CD.
CI/CD в других областях и роль Git
18:20 — 23:20Лекция расширяет идею DevOps на другие домены, прежде всего на MLOps, где модели и данные тоже рассматриваются как артефакты. Далее объясняется, почему CI/CD тесно связан с Git: код и описание пайплайнов обычно хранятся в репозитории, а значит, важны правила ветвления и работы с историей. Подчёркиваются практики аккуратной работы с коммитами, gitignore, code review и rebase.
Стратегии ветвления Git: обзор и сравнение
23:20 — 31:40Лектор вводит понятие стратегии ветвления и объясняет, что она определяет способ организации разработки и доставки кода. Сравниваются несколько моделей: OneBranchFlow, GitFlow, GitHub Flow, GitLab Flow, trunk-based и fork-based workflow. Для каждой подчёркивается компромисс между простотой, управляемостью, историей релизов и удобством интеграции с процессами Ops.
Практические замечания по Git и выбор стратегии
31:40 — 39:10На вопрос из аудитории лектор поясняет разницу между ветками, тегами и релизными ветками в GitFlow и GitLab Flow. Отдельно обсуждается, зачем сохранять релизные ветки и когда это полезно для истории, сравнения версий и поиска потерянных изменений. В ответе также даётся практический совет: для новых рабочих проектов проще всего стартовать с GitHub Flow.
Варианты деплоя: от простого до Blue-Green и Canary
39:10 — 48:20После разговора о ветвлении лекция переходит к стратегиям деплоя как отдельному слою поверх CI/CD. Сначала разбирается простой деплой и частичное обновление как базовые, но рискованные подходы. Затем подробно объясняются Blue-Green Deploy и Canary Deploy: их механика, преимущества, стоимость и способы переключения трафика.
Feature flags и rolling update
48:20 — 58:29Лектор показывает, что feature flags позволяют выкатывать код с включением и выключением функционала внутри приложения, не полагаясь на несколько копий среды. Затем объясняется rolling update как постепенное обновление реплик с проверкой здоровья через пробы, при котором трафик переводится только после готовности всех экземпляров. Обсуждаются ограничения: необходимость stateless-приложений и риск при высокой нагрузке или неудачном совпадении с апдейтом.
Ключевые цитаты
«И уже потом это попадает в продакшн. И вот как раз за это отвечает процесс CI/CD.»
«Непрерывная интеграция — это у нас сборка и первичное тестирование.»
«Continuous Delivery предполагает только ручной деплой на продакшен.»
«Continuous Deployment — это как раз про то, что у нас и выкатка в прод тоже автоматизирована.»
«Мы стараемся коммитить более часто и более мелкими.»
«Не забывать делать ребейс, потому что если вы отвели ветку, и пока вы там работали, основная ветка убежала, то всегда хорошим тоном считается ребейзинг.»
«У нас есть ветка Main, которая содержит самый актуальный код. Но этот Main мы никак не используем вообще.»
«Самый простой деплой, который существует, это, в общем-то, просто деплой.»
«Blue-Green Deploy. То есть, у нас есть две идентичные среды.»
«Можно мгновенно откатить, если вы переключили, что-то пошло не так — быстренько откатили обратно на плечо, которое ещё не обновилось.»
«Идея в чём? Мы можем просто поднять рядом вторую версию сервиса и переключать трафик.»
«Сервисы состоят из нескольких реплик, мы их обновляем постепенно.»
Глоссарий
Вопросы для самопроверки
-
Что такое CI/CD и какую проблему он решает?
Показать ответ
CI/CD автоматизирует сборку, тестирование и доставку кода, сокращая ручной труд, риск ошибок и простои при релизе. -
В чём разница между Continuous Delivery и Continuous Deployment?
Показать ответ
Delivery заканчивается ручным нажатием кнопки на этапе выкладки в прод, а Deployment доводит до автомата и сам финальный деплой. -
Почему CI/CD особенно полезен при наличии нескольких стендов?
Показать ответ
Потому что одинаковый пайплайн позволяет повторяемо проверять артефакт на разных средах и заранее ловить ошибки. -
Зачем нужна стратегия ветвления в Git?
Показать ответ
Она задаёт правила организации разработки, вливания изменений и подготовки релизов, что упрощает интеграцию с CI/CD. -
Чем GitFlow отличается от GitHub Flow?
Показать ответ
GitFlow использует develop, feature, release и hotfix ветки и больше ориентирован на релизы, а GitHub Flow проще: основная ветка и короткие feature-ветки. -
Когда уместен trunk-based development?
Показать ответ
Когда команда умеет быстро и аккуратно интегрировать изменения в одну основную ветку и хочет минимизировать ветвление. -
В чём идея Blue-Green Deploy?
Показать ответ
Есть две идентичные среды: одна активна, другая обновляется и проверяется, после чего трафик переключается на новую. -
Как работает Canary Deploy?
Показать ответ
Новая версия получает лишь часть трафика, затем доля увеличивается, если метрики и поведение в норме. -
Что дают feature flags по сравнению с отдельными средами?
Показать ответ
Они позволяют включать и выключать функционал внутри одной версии кода без необходимости держать несколько копий среды. -
Почему rolling update требует stateless-приложений?
Показать ответ
Потому что старые и новые реплики должны сосуществовать одновременно, не ломая состояние и совместную работу сервиса.