1
00:00:08,000 --> 00:01:00,000
Сегодня мы поговорим про CI/CD — про то, как код доходит до продакшна и почему этот процесс стал таким важным в современной разработке.

2
00:01:00,000 --> 00:02:20,000
Раньше выкатка кода в production была сложной, долгой, часто требовала остановки сервиса или объявления технических работ. Релиз превращался в набор ручных операций с высоким риском ошибки.

3
00:02:20,000 --> 00:04:00,000
CI/CD нужен, чтобы автоматизировать путь от разработки до продакшена. Смысл в том, чтобы собирать артефакт, проверять его на разных стадиях и доставлять в продакшн по заранее настроенному процессу.

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

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

6
00:06:20,000 --> 00:07:40,000
Непрерывная интеграция — это у нас сборка и первичное тестирование. Это может быть не один тест, а несколько: сначала проверка во время сборки, потом дополнительные тесты после.

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

8
00:09:00,000 --> 00:10:20,000
Continuous Deployment, наоборот, предполагает полностью автоматический выкат в production. Для крупных и высококритичных систем это менее безопасно — чем критичнее система, тем осторожнее с автоматизацией прода.

9
00:10:20,000 --> 00:11:40,000
Continuous Delivery — это когда мы берём результат нашего CI и везём его куда-нибудь. Continuous Deployment — это когда у нас и выкатка в прод тоже автоматизирована.

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

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

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

13
00:16:40,000 --> 00:18:20,000
Пайплайны могут быть и очень простыми, и очень сложными. В простейшем виде это последовательность «протестировали — сбилдили — задеплоили». В сложном — много этапов, сред, ручных проверок.

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

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

16
00:21:40,000 --> 00:23:20,000
Пайплайны — это не только практика, но и код. Описание того, как артефакт проходит свой путь, хранится в репозитории. Поэтому Git и стратегия ветвления становятся критически важными.

17
00:23:20,000 --> 00:25:00,000
Стратегия ветвления — это набор правил о том, как команда разрабатывает ПО, как пушит изменения, как интегрируется в общую ветку и как готовится релиз.

18
00:25:00,000 --> 00:26:40,000
Самая простая стратегия — OneBranchFlow, когда всё идёт в одну ветку. Подходит для маленьких личных проектов или ботов, где нет строгих требований к релизам.

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

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

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

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

23
00:33:20,000 --> 00:35:00,000
Мы стараемся коммитить более часто и более мелкими коммитами. Большой коммит, который копился весь день, плохо читается, плохо откатывается и неудобен для CI/CD.

24
00:35:00,000 --> 00:36:40,000
Не забывать делать ребейс — если вы отвели ветку, и пока вы там работали, основная ветка убежала, то всегда хорошим тоном считается ребейзинг перед merge.

25
00:36:40,000 --> 00:39:10,000
Если логины и пароли однажды попали в Git, они остаются в истории навсегда. Поэтому игнорирование секретов через gitignore и правильная настройка репозитория критически важны.

26
00:39:10,000 --> 00:40:50,000
Самый простой деплой, который существует, это, в общем-то, просто деплой. Обновили сервисы до новой версии, и если что-то сломалось, узнаем об этом только после выкладки.

27
00:40:50,000 --> 00:42:30,000
Похожий вариант — частичное обновление, когда не весь набор сервисов выкатывается сразу, а по очереди. Помогает уменьшить риск, но не даёт полноценной защиты от ошибок.

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

29
00:44:40,000 --> 00:46:20,000
Можно мгновенно откатить, если вы переключили, что-то пошло не так, быстренько откатили обратно на плечо, которое ещё не обновилось.

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

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

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

33
00:52:20,000 --> 00:54:20,000
Главное преимущество Canary — низкий риск: система тестируется на реальных пользователях, но только на малой доле трафика. При проблеме откатить можно быстро.

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

35
00:56:20,000 --> 00:58:29,000
Rolling update — реплики обновляются по очереди, старая и новая версии сосуществуют, а трафик на новую версию пускается только после успешных проверок. Для этого приложения должны быть stateless.