7.0 KiB
Вопросы: CI/CD
Опираются на кейс: CASE.md. Источники — Реалист банк.md, Bi.Zone.md, Alfa-Bank.md.
В чём разница между CI и CD?
CI (Continuous Integration) — автоматическая проверка кода при каждом изменении: сборка, линтинг, тесты — цель поймать проблему как можно раньше, до слияния с основной веткой. CD (Continuous Delivery/Deployment) — автоматизация доставки уже проверенного кода до среды исполнения (staging/production) — сборка артефакта/образа, публикация в registry, применение на целевой инфраструктуре. Граница на практике: CI заканчивается там, где код признан «годным» (все тесты прошли, собран артефакт), CD начинается с того, что этот артефакт доставляется дальше.
Нарисуй CI/CD и как проливается код через GitLab CI — что будет в процессе CI и что в CD (с этапа, когда код уже запушен в GitHub, а образы в Nexus)?
От push в GitHub: (1) webhook/триггер запускает pipeline в GitLab CI; (2) CI-часть — стадии lint (статический анализ) → test (юнит/интеграционные тесты, в моей практике — molecule test для Ansible-ролей) → build (сборка Docker-образа); (3) стадия публикации — образ пушится в Nexus как container registry с тегом (обычно commit SHA или семантическая версия); (4) CD-часть начинается с деплоя — pipeline берёт собранный образ именно из Nexus (не пересобирает заново) и применяет его на целевом окружении (kubectl apply/helm upgrade при K8s, или через Ansible-плейбук деплоя при классической инфраструктуре) — сначала обычно на staging, дальше по ручному approve или автоматически на production. Ключевой принцип: то, что задеплоено в prod — это тот же самый бинарный артефакт (образ), что прошёл все проверки CI, без пересборки на каждом этапе.
Что такое pipeline/stage/job?
Pipeline — весь процесс целиком, от триггера (push/MR) до конечного результата (успешный деплой или явный fail). Stage — логическая фаза внутри pipeline (например, build, test, deploy) — stages выполняются последовательно. Job — конкретная выполняемая задача внутри stage (например, в stage test могут быть параллельно запущены job unit-tests и job molecule-test) — job'ы внутри одного stage обычно выполняются параллельно, если нет явных зависимостей.
Зачем нужны protected branches?
Защита основной ветки (обычно main/master) от прямых push и слияний без прохождения обязательных проверок — требует, чтобы изменения проходили через Merge/Pull Request с обязательным прохождением CI (status checks) и, как правило, минимум одного ревью. Смысл — предотвратить попадание непроверенного или сломанного кода прямо в ветку, с которой разворачивается прод.
Как откатить плохой деплой?
Зависит от инфраструктуры: при K8s — kubectl rollout undo deployment/<name> (возврат к предыдущей ревизии Deployment) или helm rollback <release> <revision> при Helm-релизах. При классическом деплое через Ansible/образы — передеплоить предыдущий проверенный тег образа (тот самый принцип «в prod идёт конкретный собранный артефакт из registry» из вопроса про GitLab CI выше — откат это просто повторный деплой более старого тега). Важно, чтобы откат был таким же автоматизированным процессом через тот же pipeline, а не ручными правками на проде.
Чем отличается git merge --no-ff от fast-forward merge?
Fast-forward merge происходит, когда в целевой ветке не было новых коммитов после создания feature-ветки — Git просто «продвигает» указатель ветки вперёд, без создания отдельного merge-коммита, история выглядит линейной, как будто feature-ветки не было вовсе. git merge --no-ff принудительно создаёт merge-коммит, даже если fast-forward был бы возможен — это сохраняет в истории явный факт, что была отдельная ветка разработки, что удобно для читаемости истории и для возможности откатить весь набор изменений одним revert merge-коммита.
Как выглядит типичный pipeline для инфраструктурного репозитория?
lint (например, ansible-lint для проверки стиля и распространённых ошибок в ролях) → test (molecule test — идемпотентность и корректность роли в изолированном окружении, см. ../ansible/CASE.md) → deploy (применение роли/плейбука на целевую инфраструктуру, обычно с разделением на staging и production stage с ручным approve перед production). Именно эту цепочку я воспроизвёл в CASE.md — начиная с push в Gitea и заканчивая автоматическим прогоном molecule test в пайплайне.