Настройка CI/CD без перегруженных пайплайнов
Opsy упрощает цепочку от образа до кластера: меньше YAML-инженерии «на все случаи жизни».
Многие команды начинают с одного .gitlab-ci.yml и со временем превращают его в лабиринт стадий: каждый новый кейс - новые include, условия и дублирование.
CI превращается в продукт, за которым нужно отдельно ухаживать: любое изменение в инфраструктуре требует правок в десятках мест.
Страх трогать пайплайн: «вдруг сломаем прод», длинное время ожидания job’ов, неочевидные зависимости между проектами.
Промоушн между dev, staging и prod описан по-разному в каждом репозитории, хотя бизнес-логика одна и та же.
Акцент смещается с раздувания YAML в GitLab на предсказуемый путь образа в кластер и согласованный промоушн между средами.
Команда может держать CI там, где он уместен (сборка, тесты), а выкладку и продвижение - в слое, который проще сопровождать и объяснять новым людям.
Архитектурные нюансы и сравнение подходов - на странице темы «CI/CD Simplified».
GitLab удобен тем, что всё рядом: код, CI, registry, иногда даже инфраструктурные репозитории. Естественная тенденция - добавлять ещё одну стадию «на всякий случай», ещё один include и ещё одно условие only/except.
Со временем изменение инфраструктуры (новый кластер, новый registry) превращается в проект по правке десятков YAML-файлов, где легко пропустить один репозиторий.
Разработчики начинают обходить «официальный» пайплайн локальными скриптами - и формальная картина в GitLab перестаёт отражать реальность.
Иллюстрации ниже - фрагменты интерфейса Opsy из связанной темы продукта. Нажмите на снимок, чтобы открыть его на весь экран.



