CI/CD: почему это требование вышло за пределы DevOps

Требование «знать CI/CD» всё чаще встречается в вакансиях, где раньше было достаточно писать код или тесты. От вас не ждут, что вы настроите Jenkins с нуля или поднимете Kubernetes. Но ждут, что вы понимаете, как устроен процесс сборки, умеете читать логи пайплайна, добавлять в него свои шаги и не блокировать релизную цепочку. На собеседованиях проверяют именно это — способность работать внутри уже существующей инфраструктуры, а не проектировать её.

Что такое пайплайн глазами не-DevOps

Пайплайн — это автоматизированная последовательность действий, которые происходят с кодом после коммита. Для разработчика или тестировщика это не абстрактная «доставка», а конкретные этапы: сборка, прогон юнит-тестов, проверка стиля, интеграционные тесты, деплой на стенд. Каждый этап — это скрипт или конфигурация, которую можно прочитать и, при необходимости, изменить. Вы не обязаны знать, как работает агент или оркестратор, но должны понимать, где искать ошибку, если пайплайн упал. На практике это означает, что вы умеете открыть лог, найти строчку с ошибкой и хотя бы примерно определить, на каком этапе она произошла.

Требование у тестировщика: автотесты в сборке

От тестировщика в CI/CD ждут, что его автотесты станут частью пайплайна. Это не просто запуск тестов вручную после сборки, а встраивание их в цепочку так, чтобы они запускались автоматически на каждый коммит или пул-реквест. На собеседовании могут спросить, как вы добавите тест в пайплайн, который уже есть, или как настроить запуск только определённого набора тестов в зависимости от изменённых файлов. Типичная ошибка — считать, что CI/CD отвечает только за развёртывание, и игнорировать этап тестирования. В реальности пайплайн часто падает именно на тестах, и тестировщик должен уметь быстро понять, это баг кода или проблема в самом тесте.

Требование у разработчика: не сломать общую ветку

Основная задача разработчика в контексте CI/CD — не допустить, чтобы его коммит сделал сборку красной на главной ветке. Для этого используются проверки перед слиянием: линтеры, юнит-тесты, проверка покрытия. На собеседовании спросят, что вы делаете, если ваш пул-реквест не проходит сборку: перезапускаете пайплайн, исправляете код или добавляете временный хотфикс в конфигурацию. Важно показать, что вы понимаете, как чтение логов и локальный запуск тех же шагов помогает найти проблему до того, как она заблокирует команду. Распространённая ошибка — игнорировать красную сборку, надеясь, что она «сама позеленеет» после перезапуска.

ML-инженер и воспроизводимость

В ML-командах CI/CD нужен не только для кода, но и для данных и моделей. Пайплайн может включать шаги валидации данных, запуска экспериментов, сравнения метрик и упаковки модели в артефакт. От ML-инженера ждут, что он сможет добавить шаг, который проверяет, не изменилось ли распределение данных, и не даст устаревшей модели уйти в прод. На собеседовании могут спросить, как вы будете хранить версии моделей и параметров, чтобы эксперимент можно было воспроизвести через месяц. Типичная ошибка — считать, что CI/CD для ML — это просто прогон Jupyter-ноутбука, и игнорировать управление зависимостями и окружением.

Красная сборка как рабочая ситуация

Красная сборка — это нормально, но важно, как вы на неё реагируете. На собеседовании могут смоделировать ситуацию: после вашего коммита пайплайн упал на этапе интеграционных тестов, а вы не понимаете причину. Ожидаемый ответ — сначала проверить, не было ли изменений в конфигурации пайплайна или в окружении, затем посмотреть, упали ли тесты, связанные с вашим кодом, или все подряд. Если проблема не в коде, а в инфраструктуре (например, закончилось место на диске), вы должны уметь это увидеть по логам и поднять вопрос в чате. Не нужно пытаться починить всё самому, но нужно уметь отличить проблему кода от проблемы пайплайна.

Минимальный набор для собеседования

Чтобы пройти собеседование, достаточно трёх вещей. Первое — понимание этапов типового пайплайна (сборка, тесты, статический анализ, деплой). Второе — умение читать и объяснять базовый YAML-файл с последовательностью шагов (например, для GitHub Actions или GitLab CI). Третье — знание, как запустить пайплайн локально или хотя бы где искать логи на CI-сервере. Не нужно учить все команды Docker или Jenkins, но нужно уметь объяснить, что произойдёт, если в пайплайне не указать кэширование зависимостей, или почему иногда тесты на CI падают, а на локальной машине проходят.

Почему навык всё чаще обязателен

Работодатели перестали делить команды на «тех, кто пишет код» и «тех, кто настраивает доставку». CI/CD встроен в повседневную работу: любой коммит может запустить цепочку, которая повлияет на других. Если разработчик или тестировщик не понимает, как его действие скажется на пайплайне, он замедляет всю команду. Поэтому навык работы с CI/CD из специализации DevOps превратился в обязательный элемент для большинства технических ролей. В вакансиях это формулируют по-разному: «умение работать с CI/CD», «опыт интеграции тестов в пайплайн», «понимание процесса поставки». Но суть одна — от вас ждут не геройства, а предсказуемости и умения не блокировать релиз.