Агент DevOps — от коммита до продакшена
Как агент DevOps в Datarim ведёт pipeline сборки и деплоя: проектирование CI/CD, написание Dockerfile, управление секретами и оптимизация сборок.
Фича не готова, когда прошли последние тесты. Она готова, когда воспроизводимо работает в продакшене — без утечки секретов и без расхождений между окружениями. Агент DevOps отвечает за эту вторую половину пути.
Его зона ответственности — pipeline сборки, доставки и запуска: от коммита в систему контроля версий до контейнера, работающего в продакшене с проверенной конфигурацией. Сюда входят пайплайны, образы, переменные окружений и артефактные хранилища, которые всё это связывают.
Что он делает
Агент проектирует и реализует CI/CD-пайплайны — прежде всего GitHub Actions, но та же логика применима к GitLab CI и аналогам. Каждый шаг пайплайна трактуется как контракт: входные данные, выходные данные и поведение при сбое задаются явно, а не подразумеваются.
Написание Dockerfile подчиняется фиксированным принципам. Базовые образы — минимальные. Стадии сборки выстраиваются так, чтобы кэш оставался актуальным при большинстве изменений. Значения секретов никогда не попадают в слои образа — секреты передаются через переменные окружения, vault или CI-секреты, без жёсткого прописывания. Тот же образ, что прошёл staging, и деплоится в продакшен: паритет окружений не опционален.
Оптимизация сборок
Медленные пайплайны подрывают дисциплину — разработчики начинают пропускать шаги. Время сборки рассматривается как ограничение первого класса. Независимые шаги выполняются параллельно. Ключи кэша формируются так, чтобы пересобирались только реально изменившиеся слои. Артефакты сохраняются один раз и продвигаются между стадиями, а не пересобираются на каждом окружении.
Конкретный пример: сервис на Node.js, который пересобирал слой node_modules при каждом пуше, реструктурируется так, чтобы слой зависимостей пересобирался только при изменении package-lock.json. Слой приложения пересобирается на каждый пуш, но он тонкий.
Место в процессе
Агент DevOps подключается на /dr-plan при проектировании инфраструктурных решений, на /dr-do при написании Dockerfile и CI-конфигурации, и на /dr-compliance для анализа влияния изменений на CI/CD до закрытия задачи. Руководство по Infrastructure-as-Code — Terraform, Pulumi, Ansible — входит в его компетенцию, когда этого требует план.
Полный справочник — на карточке агента DevOps, а общая картина — в посте что такое Datarim.