DevOps

GitHub Actions и GitLab CI

В 2020 году команда из 5 разработчиков тратила 2 часа в день на ручной деплой. После настройки CI/CD pipeline это время сократилось до 0 - pipeline сам собирает, тестирует и деплоит при каждом push. GitHub Actions и GitLab CI - два самых популярных инструмента, которые делают это бесплатно для большинства проектов.

**Vercel и Netlify** используют GitHub Actions под капотом - каждый push в main автоматически деплоится на CDN
**npm publish** тысяч open-source пакетов полностью автоматизирован через GitHub Actions при создании GitHub Release
**GitLab CI** используется в Airbus, CERN, NASA JPL для критически важных CI/CD процессов с self-hosted runners

Структура pipeline

Каждый раз когда разработчик пушит код, в компании X происходит цепочка: сборка, тесты, линтер, деплой. Раньше это делали вручную - теперь это **pipeline**. Pipeline - это последовательность автоматических шагов, превращающих изменение кода в рабочий продукт.

В GitLab CI pipeline описывается в `.gitlab-ci.yml`. Ключевые понятия: **stage** (этап), **job** (задача внутри этапа), **runner** (машина, выполняющая job). Jobs одного stage выполняются параллельно, stages - последовательно.

**needs:** в GitLab CI позволяет строить DAG-зависимости между jobs, минуя барьер stage. Job `run-tests` стартует сразу после `build-app`, не дожидаясь других build-jobs. Это сокращает время pipeline на 30-50%.

В GitLab CI два job в одном stage: `lint` и `test`. Как они выполняются по умолчанию?

Workflows и триггеры GitHub Actions

GitHub Actions использует термин **workflow** вместо pipeline. Workflow - это YAML-файл в `.github/workflows/`, который описывает: когда запускаться (`on:`), где запускаться (`runs-on:`) и что делать (`steps:`). Одно событие может запускать несколько workflows параллельно.

Система триггеров богаче, чем в GitLab: `push`, `pull_request`, `schedule` (cron), `workflow_dispatch` (ручной запуск с параметрами), `workflow_call` (вызов из другого workflow), `release`, `issue_comment`. Каждый триггер можно фильтровать по веткам, тегам, путям файлов.

**Reusable workflows** (`workflow_call`) позволяют вынести общую логику (например, сборку Docker-образа) в отдельный файл и вызывать его из разных workflows. Это аналог функций для CI/CD - избегайте copy-paste между репозиториями.

Workflow должен запускаться только при push в ветки `main` или `release/*`, но не при изменении файлов `*.md`. Какая комбинация нужна?

Self-hosted runners

GitHub-hosted runners (ubuntu-latest, macos-latest) удобны, но имеют ограничения: 2 vCPU, 7 GB RAM, нет доступа к внутренней сети. **Self-hosted runner** - это собственная машина, зарегистрированная в GitHub/GitLab, которая выполняет jobs. Нужен для: доступа к on-premise ресурсам, GPU-вычислений, специфичного ПО, экономии на minutes.

В GitLab self-hosted runner называется **GitLab Runner**. Он поддерживает несколько executor-ов: `shell` (команды в shell машины), `docker` (изоляция в контейнере - рекомендуется), `kubernetes` (pod на каждый job). Для production всегда используйте docker executor - он изолирует среду между jobs.

**Безопасность:** self-hosted runners в публичных репозиториях опасны - злоумышленник может создать PR с вредоносным кодом. Используйте self-hosted только в приватных репозиториях или настройте `require approval` для fork-PR.

Команда нуждается в доступе к внутренней БД при тестах. Какое решение правильное?

Artifacts и кэш

Pipeline часто состоит из нескольких jobs на разных машинах. Как job `deploy` получит собранный бинарь из job `build`? Через **artifacts** - файлы, которые job сохраняет после завершения, и которые другие jobs (или пользователь) могут скачать.

**Кэш** решает другую задачу: ускорение pipeline за счёт переиспользования неизменяемых данных между запусками. `node_modules`, pip-пакеты, gradle-кэш - скачиваются один раз, хранятся на runner или в облаке, используются повторно. Кэш не гарантирован - pipeline должен работать и без него.

**Разница artifacts vs cache:** artifacts - результат работы (бинарь, отчёт тестов, скриншоты), хранятся гарантированно, доступны между jobs и пользователям. Cache - ускоритель (зависимости), может не найтись (cache miss), не должен содержать результаты сборки.

Cache и artifacts взаимозаменяемы - оба хранят файлы между jobs

Artifacts - надёжное хранилище результатов с гарантией наличия. Cache - оптимизация скорости без гарантий.

Cache может не найтись (cache miss) - и это нормально. Artifacts всегда доступны до истечения retention-days.

Job `security-scan` должен опубликовать HTML-отчёт, доступный для скачивания из UI после завершения pipeline. Что использовать?