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

_длительность: 58 мин_

**[0:08]** Сегодня мы поговорим про CI/CD — про то, как код доходит до продакшна и почему этот процесс стал таким важным в современной разработке.

**[1:00]** Раньше выкатка кода в production была сложной, долгой, часто требовала остановки сервиса или объявления технических работ. Релиз превращался в набор ручных операций с высоким риском ошибки.

**[2:20]** CI/CD нужен, чтобы автоматизировать путь от разработки до продакшена. Смысл в том, чтобы собирать артефакт, проверять его на разных стадиях и доставлять в продакшн по заранее настроенному процессу.

**[4:00]** До появления этих подходов было много ручной рутины: сборки делали вручную, копировали файлы вручную, ставили на серверы вручную. Это замедляло релизы и увеличивало вероятность ошибок.

**[5:00]** Теперь разберёмся с расшифровкой. CI/CD — это Continuous Integration и Continuous Delivery или Continuous Deployment. Первая часть, CI, отвечает за автоматическую интеграцию изменений: сборку кода, первичное тестирование.

**[6:20]** Непрерывная интеграция — это у нас сборка и первичное тестирование. Это может быть не один тест, а несколько: сначала проверка во время сборки, потом дополнительные тесты после.

**[7:40]** Continuous Delivery и Continuous Deployment — это разные вещи, хотя обе сокращаются как CD. Continuous Delivery означает, что весь путь автоматизирован, но финальный деплой на production делается вручную.

**[9:00]** Continuous Deployment, наоборот, предполагает полностью автоматический выкат в production. Для крупных и высококритичных систем это менее безопасно — чем критичнее система, тем осторожнее с автоматизацией прода.

**[10:20]** Continuous Delivery — это когда мы берём результат нашего CI и везём его куда-нибудь. Continuous Deployment — это когда у нас и выкатка в прод тоже автоматизирована.

**[11:40]** Перейдём к пайплайнам. Типичная схема CI/CD: код коммитится, начинается билд, прогоняются юнит-тесты, интеграционные тесты, артефакт деплоится в стейджинг и потом в production.

**[13:20]** Для примера возьмём GitLab. Код коммитится, запускается сборка, на CI-этапе проходят unit-тесты и integration tests, потом пайплайн переходит в CD и выкатывает артефакт в staging.

**[15:00]** Важное свойство таких схем — наличие промежуточных тестовых стендов: acceptance-тесты, интеграционные тесты, smoke-тесты. Если система состоит из нескольких сервисов, надо проверять не только каждый отдельно.

**[16:40]** Пайплайны могут быть и очень простыми, и очень сложными. В простейшем виде это последовательность «протестировали — сбилдили — задеплоили». В сложном — много этапов, сред, ручных проверок.

**[18:20]** Идея CI/CD оказалась настолько удобной, что её стали переносить в другие области. Например, MLOps — то же самое, но вместо обычного артефакта рассматривается модель машинного обучения.

**[20:00]** Для MLOps логика похожая: модель циклически обучают, упаковывают как артефакт, хранят в виде образа или вольюма и автоматически деплоят. Процесс остаётся тем же — итерационная доставка.

**[21:40]** Пайплайны — это не только практика, но и код. Описание того, как артефакт проходит свой путь, хранится в репозитории. Поэтому Git и стратегия ветвления становятся критически важными.

**[23:20]** Стратегия ветвления — это набор правил о том, как команда разрабатывает ПО, как пушит изменения, как интегрируется в общую ветку и как готовится релиз.

**[25:00]** Самая простая стратегия — OneBranchFlow, когда всё идёт в одну ветку. Подходит для маленьких личных проектов или ботов, где нет строгих требований к релизам.

**[26:40]** GitFlow — одна из самых популярных схем. Есть стабильная ветка Main, которая хранит самый актуальный stable-код, но активно не используется. Основная рабочая ветка — Develop.

**[28:20]** У нас есть ветка Main, которая содержит самый актуальный код из возможных. Но, тем не менее, этот Main мы никак не используем вообще — он только для релизов.

**[30:00]** Когда мы видим, что какое-то супер мелкое изменение нужно срочно закатить — в таких случаях существует сущность hotfix. Она создаётся прямо от main и быстро возвращается обратно.

**[31:40]** Среди плохих практик — пушить всё в один main без веток, использовать бессмысленные коммит-месседжи вроде test, debug, final try. Это ухудшает читаемость истории.

**[33:20]** Мы стараемся коммитить более часто и более мелкими коммитами. Большой коммит, который копился весь день, плохо читается, плохо откатывается и неудобен для CI/CD.

**[35:00]** Не забывать делать ребейс — если вы отвели ветку, и пока вы там работали, основная ветка убежала, то всегда хорошим тоном считается ребейзинг перед merge.

**[36:40]** Если логины и пароли однажды попали в Git, они остаются в истории навсегда. Поэтому игнорирование секретов через gitignore и правильная настройка репозитория критически важны.

**[39:10]** Самый простой деплой, который существует, это, в общем-то, просто деплой. Обновили сервисы до новой версии, и если что-то сломалось, узнаем об этом только после выкладки.

**[40:50]** Похожий вариант — частичное обновление, когда не весь набор сервисов выкатывается сразу, а по очереди. Помогает уменьшить риск, но не даёт полноценной защиты от ошибок.

**[42:30]** Blue-Green Deploy. У нас есть две идентичные среды, или два «плеча». Одно плечо в каждый момент времени простаивает, а другое обслуживает трафик. Сначала обновляют простаивающее плечо.

**[44:40]** Можно мгновенно откатить, если вы переключили, что-то пошло не так, быстренько откатили обратно на плечо, которое ещё не обновилось.

**[46:20]** Минус Blue-Green — высокая стоимость: нужно держать две полные копии прода, причём одна всё время простаивает. Поэтому используют в критичных инфраструктурах, где важен быстрый rollback.

**[48:20]** Canary-деплой похож на Blue-Green, но более гибкий и дешёвый. Не обязательно иметь целое второе плечо: достаточно поднять новую версию сервиса рядом со старой и постепенно перенаправлять трафик.

**[50:20]** Идея в чём? Что мы можем просто поднять рядом вторую версию сервиса и переключать трафик. Например, сначала 25% пользователей идут на новую версию, а 75% остаются на старой.

**[52:20]** Главное преимущество Canary — низкий риск: система тестируется на реальных пользователях, но только на малой доле трафика. При проблеме откатить можно быстро.

**[54:20]** Feature flags — более точечный механизм. Внутри одного и того же кода включают или выключают функции через флаги. Удобно, когда физически невозможно держать две копии сервиса.

**[56:20]** Rolling update — реплики обновляются по очереди, старая и новая версии сосуществуют, а трафик на новую версию пускается только после успешных проверок. Для этого приложения должны быть stateless.