← вся теориятеория к собесу · Инфраструктура данных

CI/CD в дата-инженерии

CI/CD: зелёный main как контракт

CI/CD автоматизирует путь от пуша до прода: сборка, тесты, деплой. Собес проверяет, понимаешь ли ты принцип build once - promote и почему миграции схемы должны быть кодом.

Стержень: артефакт собирается один раз и продвигается через среды неизменным; зелёный main - контракт команды.

// Формулировки: «как устроен CI-пайплайн?», «что значит build once, promote?», «где хранить секреты пайплайна?».

CI: ломаться быстро и дёшево

CI это автоматическая сборка, линт и тесты на каждый пуш: ломается быстро и у автора, а не в проде через неделю. Зелёный main - контракт команды, на который все опираются.

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

// Скорость петли - тоже метрика: CI дольше 10–15 минут перестают ждать, начинают мержить «на красное» и батчить изменения. Зависимости кэшируют, тесты параллелят.

pipeline stage: ступень: линт → тесты → сборка → деплой
зелёный main: рабочее состояние ветки как контракт команды

Build once, promote

Артефакт собирают один раз и продвигают через среды (dev → stage → prod) неизменным. Пересборка «того же» кода на каждую среду даёт формально разные артефакты, и рождает классическое «на стейдже работало, в проде нет».

CD это деплой автоматикой из пайплайна (rolling, canary), а не руками с ноутбука; откат - та же кнопка с прошлой версией.

// Для данных CI дополняют своим: dbt build/test на PR (slim CI - только изменённые модели против прод-стейта), валидация DAG (directed acyclic graph)'ов Airflow, dry-run миграций.

build once, promote: один артефакт продвигается через среды неизменным
canary deploy: новая версия на доле трафика с наблюдением

Миграции и секреты

Миграции схемы - код в репозитории (alembic, flyway), применяемый пайплайном до или вместе с деплоем. Вручную правленная прод-схема это дрейф, который однажды выстрелит несовместимостью с кодом.

Секреты держат в хранилище CI или vault, не в репозитории; пайплайн получает их на время запуска.

// Ключ, попавший в git-историю, считается скомпрометированным навсегда - вычистить из истории мало, его надо ротировать. Токены с широким доступом в переменных репозитория или в логах пайплайна - типичная утечка.

migration as code: версионированные миграции схемы в репозитории
slim CI (dbt): прогон только изменённых моделей против прод-стейта

Как отвечать: «Что значит build once, promote и зачем так?»

Это принцип: собрать артефакт - образ, пакет - ровно один раз и дальше двигать этот же самый артефакт через среды, dev, stage, prod, ничего не пересобирая. Смысл в том, что тестируешь и выкатываешь бит-в-бит одно и то же. Если вместо этого пересобирать «тот же» код на каждую среду, ты получаешь формально разные артефакты: другая версия базового образа, другой снапшот зависимостей, другое время сборки, и вылезает классическое «на стейдже работало, а в проде упало», потому что в прод уехало не то, что проверяли на стейдже. Поэтому в пайплайне сборка - отдельная ступень в начале, а деплой на каждую среду просто продвигает готовый артефакт по закреплённому тегу или digest. Откат - тоже продвижение, но предыдущей версии. Так релиз становится воспроизводимым, а не «пересоберём и помолимся».

Почему это сильный ответ: принцип объяснён через воспроизводимость (тестируешь то же, что катишь), назван конкретный сбой пересборки («на стейдже работало») и связь с откатом по версии.

На чём валят

−Тесты «локально прогоню» - CI без обязательных проверок деградирует в формальность.
−Разные образы на stage и prod (пересборка) - «на стейдже работало».
−Миграции руками в прод-консоли - схема разъехалась с кодом навсегда.
−Токены в переменных репозитория с широким доступом или в логах пайплайна.
−Часовой CI: команда мержит не дожидаясь - красный main как норма.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 11, остальные разбираются в тренажёре.

#cicd1 / 5
Что обычно является артефактом сборки в CI/CD для контейнеризированного пайплайна?
A)Артефакт — это исходный код в git, который каждая среда сама пересобирает в образ при деплое
B)Артефактом является запущенный контейнер в проде, который CI переносит между серверами
C)Собранный и версионированный Docker-образ, запушенный в реестр — неизменяемый артефакт, который затем деплоят в среды
D)Артефакт CI — это лог выполнения тестов, который и деплоят в продакшен-среду
показать ответ и разбор
+C)Собранный и версионированный Docker-образ, запушенный в реестр — неизменяемый артефакт, который затем деплоят в среды
// разбор: В контейнерном пайплайне артефакт CI — это собранный Docker-образ, помеченный версией/commit-хешем и запушенный в реестр. Ключевое свойство — неизменяемость: собрали образ один раз, прогнали на нём тесты, и ровно этот же образ продвигают по средам (stage → prod). Не пересобирают отдельно под прод (иначе тестировали одно, а деплоят другое). По тегу образа всегда понятно, какая версия где крутится, и откат — это деплой прошлого тега. Собирать образ заново на каждой среде из исходников — антипаттерн, ломающий воспроизводимость.
#cicd2 / 5
Зачем в CI/CD заводят отдельные среды dev / staging / prod?
A)Среды нужны чтобы разные команды не видели код друг друга, к тестированию это не относится
B)Достаточно одной среды prod: тестировать изменения лучше сразу на реальных пользователях
C)Среды различаются версией самого кода: в dev она новее, в prod старее
D)Постепенная проверка dev→staging→prod до боевого окружения без риска
показать ответ и разбор
+D)Постепенная проверка dev→staging→prod до боевого окружения без риска
// разбор: Отдельные среды дают ступенчатую проверку. Dev — быстрые эксперименты разработчика. Staging — окружение, максимально похожее на прод (та же инфраструктура, реалистичные данные), где прогоняют интеграционные и приёмочные проверки без риска для реальных пользователей. Prod — боевая. Изменение продвигается dev → staging → prod, различаясь между средами лишь конфигом (тот же образ). Так регрессии и проблемы масштаба ловятся на staging, а не на живых пользователях/данных. Деплой сразу в прод, минуя staging, — рискованная практика, оправданная лишь для мелких выверенных изменений.
#cicd3 / 5
Что такое GitOps как подход к доставке?
A)Git = желаемое состояние, агент сверяет и подтягивает кластер к нему
B)GitOps означает хранить исходный код приложения в git, а деплой выполнять вручную с ноутбука
C)GitOps — это запуск CI-тестов при каждом коммите без какого-либо влияния на состояние прода
D)В GitOps ручные изменения в кластере имеют приоритет над описанием в git-репозитории
показать ответ и разбор
+A)Git = желаемое состояние, агент сверяет и подтягивает кластер к нему
// разбор: GitOps: желаемое состояние системы (манифесты K8s, конфиги, версии образов) описано декларативно в git-репозитории, который становится единственным источником истины. Специальный агент (ArgoCD, Flux) непрерывно сравнивает реальное состояние кластера с описанным в git и подтягивает кластер к нему (reconciliation). Деплой = merge в git, откат = git revert, а любое ручное изменение в кластере агент вернёт к состоянию из репозитория. Плюсы: полная аудируемость (кто/что/когда через историю git), воспроизводимость, отказ от «кликанья» в проде. Особенно удобно для управления K8s-развёртываниями.
#cicd4 / 5
Как в CI/CD правильно обращаться с секретами (пароли БД, токены, ключи)?
A)Секреты удобнее всего хранить прямо в git-репозитории рядом с кодом, что упрощает деплой
B)Секреты во внешнем защищённом сторедже, инъекция в рантайме, не в git
C)Достаточно вписать пароли в Dockerfile — внутри образа они надёжно защищены от посторонних
D)Секреты нужно передавать открытым текстом в аргументах командной строки при каждом запуске
показать ответ и разбор
+B)Секреты во внешнем защищённом сторедже, инъекция в рантайме, не в git
// разбор: Секреты никогда не хранят в коде или git (даже приватном): попав в историю, они утекают и требуют ротации. В CI/CD их держат в защищённом хранилище — секретах CI-системы (masked variables GitLab/GitHub), секрет-менеджере (Vault, cloud secret manager) — и подставляют в пайплайн как переменные окружения на время выполнения, маскируя в логах. То же в K8s (Secret + внешний стор). Захардкоженный в Dockerfile/скрипт токен — классическая утечка (он уедет и в реестр образов). Хорошая практика — ещё и сканеры секретов в CI, ловящие случайный коммит ключа.
#cicd5 / 5
Что дают стратегии blue-green и canary при деплое сервиса?
A)Blue-green и canary выкатывают новую версию сразу всем пользователям без возможности отката
B)Это стратегии резервного копирования данных, а не выката новых версий сервиса
C)Blue-green — мгновенный свитч/откат; canary — новая версия на часть трафика
D)Canary означает полную остановку сервиса на время деплоя новой версии приложения
показать ответ и разбор
+C)Blue-green — мгновенный свитч/откат; canary — новая версия на часть трафика
// разбор: Обе снижают риск выката. Blue-green: параллельно работают две среды — текущая (blue) и новая (green); трафик мгновенно переключают на green, а при проблеме так же мгновенно возвращают на blue (быстрый откат, нет долгого передеплоя). Canary: новую версию выкатывают малой доле трафика/пользователей, следят за метриками и ошибками, и лишь при хорошем результате расширяют до 100% — так дефект задевает немногих. Обе противопоставлены рискованному «выкатить всем сразу». Для дата-сервисов (API поверх данных, стрим-обработчики) это снижает радиус поражения плохого релиза.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.

Открыть тренажёр Вся тема: Инфраструктура данных