Ландшафт инструментов

Две большие группы

Инструменты CI/CD грубо делятся на две категории:

1. Pipeline-движки — запускают сборку/тесты/деплой по событию из git. GitLab CI, GitHub Actions, Jenkins, CircleCI.
2. GitOps / continuous delivery для Kubernetes — следят за тем, чтобы состояние кластера совпадало с git. Argo CD, Flux.

Большинство начинающих стартуют с первой группы. GitOps — тема, к которой приходят вместе с Kubernetes.

Встроенные в git-хостинг

GitLab CI/CD. Конфиг — файл .gitlab-ci.yml в корне репозитория. CI встроен прямо в GitLab, ничего отдельно ставить не надо. Сильная интеграция: registry, environments, защита веток — всё в одном месте. Этот сайт собирается именно на нём (разберём в следующем уроке).

GitHub Actions. Конфиг — YAML-файлы в .github/workflows/. Огромный маркетплейс готовых "экшенов" (переиспользуемых шагов). Де-факто стандарт для проектов на GitHub.

Общая черта: CI живёт рядом с кодом, конфиг — YAML в репозитории, запускается по push/MR. Освоив один, второй читаешь почти без обучения.

Самостоятельные серверы

Jenkins. Старожил, ставится отдельным сервером. Очень гибкий, тысячи плагинов, pipeline описывается на Groovy (Jenkinsfile). Минусы: требует обслуживания (сам сервер, плагины, обновления), UI устаревший. Много где живёт в легаси, на новых проектах выбирают реже.

CircleCI — облачный движок, конфиг тоже YAML. Сейчас его теснят встроенные GitLab CI и GitHub Actions. Travis CI был популярен в эпоху open-source на GitHub, но после 2021 года почти ушёл со сцены.

Drone в статьях всё ещё подают как живой открытый движок, хотя это уже не так. Проект купила Harness, развитие открытой версии остановилось, а вокруг неё вырос форк Woodpecker CI. Его и берут, когда хочется лёгкий self-hosted движок в духе Drone. Само имя Drone теперь означает продукт внутри платформы Harness.

GitOps: Argo CD и Flux

Отдельный подход для Kubernetes. Идея: git — единственный источник правды о том, что должно быть в кластере. В репозитории лежат манифесты (описание желаемого состояния), а агент в кластере постоянно сверяет реальность с git и подтягивает изменения.

• push-модель (обычный CI): пайплайн сам идёт в кластер и выкатывает.
• pull-модель (GitOps): агент в кластере сам тянет из git то, что должно быть.

Плюс pull-модели: кластеру не нужно давать доступ извне, и любой "дрейф" (кто-то поменял руками) автоматически откатывается к тому, что в git. Argo CD и Flux — два главных инструмента. Это уровень после docker+k8s, упоминаем для общей картины.

Что общего у всех

Не зацикливайся на конкретном инструменте. Концепции одни:

• конфиг как код в репозитории (обычно YAML),
• stages/jobs, runners/agents,
• секреты в хранилище, артефакты, окружения,
• запуск по событию из git.

Выучив CI/CD на одном движке, на другой переезжаешь за день: меняется синтаксис, не идеи.

Что выбрать новичку

Бери тот, что встроен в твой git-хостинг: GitHub -> Actions, GitLab -> GitLab CI. Не нужно поднимать сервер, всё рядом с кодом, и навык прямо переносится на работу. Jenkins учи, когда столкнёшься с ним в легаси; Argo CD — когда дойдёшь до Kubernetes.

Что важно запомнить

Две группы: pipeline-движки (GitLab CI, GitHub Actions, Jenkins) и GitOps для k8s (Argo CD, Flux).

Встроенные в хостинг (GitLab CI, GitHub Actions) — лучший старт: YAML рядом с кодом, ничего не ставить.

Jenkins — мощный, но требует своего сервера; чаще встречается в легаси.

GitOps = git как источник правды, pull-модель: агент в кластере сам подтягивает изменения.

Инструменты разные, концепции одни. Учится один, переносится на все.

В следующем уроке разберём настоящий .gitlab-ci.yml, которым деплоится этот сайт.