На проекте с .NET 8 у нас было 8 разработчиков, staging, production и сборка образов в Docker Hub. На старте GitLab выглядел самым рациональным вариантом: быстро поднять репозиторий, настроить CI/CD и не тащить лишние правила. Главный тормоз оказался в другом - согласования, доступы в production и попытки восстановить состав релиза по задачам, коммитам и чату.
Переплата за платформу редко видна в первый месяц. Обычно она всплывает через 6-12 месяцев, когда добавляются роли, отдельные окружения, аудит изменений и второй-третий сервис. В этот момент уже важно не только, как собирается пайплайн, но и можно ли за несколько минут понять, кто одобрил выкладку и что именно уехало в production.
Основные потери начинаются между задачей, кодом и выкладкой
Для бизнеса важен простой маршрут: задача - код - проверка - production, без SSH, чата и ручных сверок. На проектах до 10 человек CI редко становится главным узким местом. По сути, все обычно упирается в права на production, ручной сбор состава релиза и разрыв между задачей и деплоем.
Azure DevOps ценят не только из-за Pipelines. Boards, Repos, Test Plans и Artifacts дают одно место, где видна связь между задачей, коммитом, выкладкой и подтверждением релиза. Это становится полезно не на презентации, а после инцидента, когда надо быстро собрать историю изменений.
В B2B SaaS у клиента было 4 сервиса, 3 окружения, задачи в Jira, код в GitLab, релизный список в Notion и согласование в Telegram. Самым болезненным местом был состав релиза: тимлид перед каждой выкладкой 30-40 минут вручную сверял merge request с закрытыми задачами. Мы не делали большой переезд, а собрали единый процесс за 5 недель. Медианное время согласования релиза по 11 выкладкам снизилось на 34%.
Если платформа не хранит след изменения целиком, команда почти всегда достраивает процесс людьми.
GitLab быстрее поднимается, Azure DevOps чаще выигрывает на зрелом процессе
Если у вас 5-7 человек, один сервис и релиз раз в неделю, GitLab обычно проще. В прошлом году мы подняли такой контур за 4 дня: репозиторий, GitLab runners в Docker, сборка сервиса, выкладка в staging и ручной деплой в production. Для небольшой команды этого хватало.
Azure DevOps становится выгоднее на стадии, где уже есть Azure, Microsoft Entra ID, группы доступа, SSO и требования к истории изменений для аудита. Там чаще платят не за сам CI/CD, а за управляемость процесса: кто может выкладывать, кто подтверждает шаг, где хранится история.
| Критерий | GitLab | Azure DevOps |
|---|---|---|
| Старт для маленькой команды | Быстрее | Дольше |
| Доступы и аудит | Достаточно для простого контура | Сильнее из коробки |
| Связка с .NET и Azure | Нормально | Естественнее |
| Порог внедрения | Ниже | Выше |
Для команды на 40+ человек с несколькими сервисами и обязательным аудитом Azure DevOps стал дешевле к 8 месяцу. Мы считали не только лицензии, но и время релиз-менеджмента, сопровождение прав, ручные согласования и восстановление истории изменений после инцидентов. Я не считаю этот вывод универсальным: если у вас уже аккуратно собран GitLab с group-level governance, миграция в Azure DevOps может ничего не сэкономить.
Сравнивать надо не синтаксис, а управление релизом
Когда спорят про GitLab CI и Azure Pipelines, обсуждение часто уходит в YAML. На деле потом всплывают другие вопросы: кто открыл доступ в production, кто подтвердил выкладку, где хранится состав релиза и можно ли поднять это через полгода без памяти тимлида.
В Azure DevOps это чаще собирается через environments, checks, service connections и approvals на уровне окружения. В GitLab - через protected branches, protected environments, права на деплой и отдельные правила для runners. Оба варианта рабочие, но в GitLab обычно больше договоренностей, которые команда удерживает дисциплиной.
# схематично
# Azure DevOps:
# approval на production обычно задают через environment checks,
# а не одной строкой в stage
# GitLab:
deploy_prod:
stage: production
when: manual # это ручной запуск job, а не полный аналог approvals
environment: production
В торговой компании исходная схема была совсем слабой: SSH-деплой "с сервера по памяти", прямой доступ в production у нескольких человек, история выкладки только в чате. Мы закрыли прямой доступ и вынесли релиз в пайплайн. За квартал число инцидентов после релиза снизилось с 17 до 10, то есть на 41%.
Сложная платформа не чинит сырой процесс
Один кейс у нас провалился. Команда на 7 человек решила сразу включить Boards, Test Plans, self-hosted agents, несколько environments и длинную цепочку согласований. Через 8 недель половина шагов все равно обходилась вручную, пайплайны понимал один инженер, а скорость релиза почти не изменилась.
Здесь ошиблись и мы: переоценили готовность команды к процессу и слишком рано принесли тяжелую схему. Люди еще не договорились о ветках, ролях и правилах релиза. В такой ситуации Azure DevOps просто сделал хаос дороже.
Признаки, что вам пока не нужен сложный контур:
- релизы идут редко и по одному сервису;
- строгого аудита и SSO еще нет;
- production меняют 1-2 человека;
- GitLab runners или Azure agents будет вести тот же разработчик между задачами.
Что проверить до выбора, чтобы не платить дважды
Я обычно прошу команду ответить на пять вопросов без подготовки:
- где живет путь от задачи до production;
- сколько ручных шагов и SSH-доступов осталось;
- кто сопровождает GitLab runners или Azure agents;
- что сломается, если через полгода сервисов станет вдвое больше;
- можно ли за 10 минут восстановить состав последнего релиза.
На ближайшие 3 дня этого достаточно: возьмите один сервис, распишите текущий путь выкладки и отметьте все, что держится на чате, памяти и ручном доступе. Если таких мест больше трех, вы пока выбираете не между GitLab и Azure DevOps. Выбираете вы, грубо говоря, только одно: когда именно заплатите за хаос.
