Традиционный CI/CD строится на конфигах: GitLab CI, GitHub Actions, Jenkins — везде нужны YAML или DSL. Это даёт гибкость, но увеличивает порог входа и количество ошибок. Разработчик, который только пришёл в проект, может потратить день на то, чтобы разобраться в чужих джобах и стадиях. Можно ли обойтись без ручного написания пайплайнов? Уже можно — и вот как.
Проблемы YAML в CI/CD
Конфиги легко разрастаются: один проект — 200 строк, другой — 500. Сложно переиспользовать шаги между проектами: в каждом репозитории свои правила именования, секреты и переменные. Легко ошибиться в отступах (YAML чувствителен к пробелам) или в ключах — и пайплайн падает на этапе, который казался простым.
Типичные боли:
- Дублирование — одинаковые шаги (lint, test, build) копируются из проекта в проект с небольшими отличиями.
- Сложность отладки — когда джоб падает, нужно разбираться в логике «почему этот шаг зависит от того».
- Время онбординга — новый человек тратит дни на изучение правил и примеров, прежде чем сможет что-то поменять.
- Хрупкость — изменение одного шага нередко требует правок в нескольких местах (переменные, артефакты, зависимости).
AI как слой абстракции
Подход «описать задачу — получить конфигурацию» уже реализуется в ряде инструментов. Вы формулируете цель на естественном языке, например: «собрать Docker-образ, прогнать тесты, задеплоить в staging» — а система генерирует или подбирает готовые шаги. Это не отменяет YAML под капотом, но переносит его написание в зону ответственности платформы, а не разработчика.
Такой подход особенно ценен для платформ AI-деплоя: вы указываете, что хотите сделать (собрать, протестировать, выкатить), а конфигурация пайплайна создаётся автоматически. Разработчик фокусируется на бизнес-логике, а не на синтаксисе.
Реальный workflow
На практике гибридная модель оказывается самой удобной:
- Типовые пайплайны — build, test, deploy в staging — задаются шаблонами или AI. Один раз описали, много раз переиспользовали.
- Редкие и специфичные шаги — кастомные скрипты, интеграции с внутренними системами — по-прежнему пишутся вручную, когда это оправдано.
Так CI/CD остаётся гибким, но доля ручного YAML снижается, а время на настройку нового проекта — с часов до минут. Команда меньше тратит времени на «подкрутить конфиг» и больше — на продукт.
Что это значит для вас
Полный отказ от YAML в CI/CD пока не стал отраслевым стандартом. Но движение в сторону декларативного описания целей и автоматической генерации конфигов уже меняет то, как команды настраивают пайплайны. Если вы только начинаете — рассмотрите инструменты с AI-поддержкой. Если уже сидите на YAML — присмотритесь к шаблонам и генераторам: они могут снять 70–80% рутины. Подробнее о деплое без лишнего YAML читайте в статье Kubernetes без Helm.