GitLab 10.0: Auto DevOps и SAST из коробки - CI/CD за полчаса вместо Jenkinsfile

GitLab 10.0 вышел на этой неделе. Главная фича релиза - Auto DevOps: GitLab сам определяет язык проекта, сам строит pipeline, сам деплоит в Kubernetes. Без .gitlab-ci.yml. Без ручной конфигурации. Мы поставили на один из проектов клиента и посмотрели что из этого получается.

Контекст: откуда растёт проблема

У небольших команд с CI/CD традиционно одна из двух крайностей. Либо «у нас Jenkins, но конфиг писал Вася три года назад, Вася ушёл, трогать страшно» - и тогда пайплайн существует номинально, обновляется раз в никогда. Либо «CI у нас нет, надо настроить, но некому и некогда» - и тогда деплой это git pull на сервере вручную.

У заказчика была вторая история: команда из четырёх разработчиков, проект на Ruby, GitLab уже стоит на managed инфраструктуре, но CI не поднят. Jenkinsfile никто не писал - не потому что не знают как, а потому что каждый раз откладывали на потом.

GitLab 10.0 с Auto DevOps выглядел как способ закрыть этот вопрос одним переключателем.

Что делает Auto DevOps

Механика такая: в настройках проекта включается Auto DevOps, GitLab анализирует репозиторий через Heroku Buildpacks и строит pipeline из стандартных шаблонных стадий.

Для Ruby-проекта это выглядело так:

• Auto Build - собирает Docker-образ через buildpack без Dockerfile в репозитории. Находит Gemfile, понимает что это Ruby, использует соответствующий buildpack.
• Auto Test - запускает тесты внутри собранного образа. В нашем случае поднял bundle exec rspec без какой-либо конфигурации.
• Auto Code Quality - запускает Code Climate, результат видно прямо в merge request.
• Auto SAST - статический анализ на уязвимости. Это пришло в CE, раньше было только в EE.
• Auto Review Apps - деплоит каждый branch в отдельное окружение на Kubernetes для ревью.
• Auto Deploy - деплоит master в staging/production на Kubernetes.

Всё это без единой строчки написанного нами CI-конфига.

Что получилось на практике

Первый запуск pipeline прошёл примерно за 12 минут. Тесты зелёные, образ собран, SAST отработал и нашёл две потенциальных проблемы в зависимостях - одна реальная (outdated gem с CVE), одна ложноположительная.

Дальше пошли нюансы.

Auto Build через buildpack работает, но образы получаются крупнее чем при ручном Dockerfile. Buildpack тянет полное Ruby-окружение включая build-tools, которые в production не нужны. Мы переходили на multi-stage builds в июле именно чтобы от этого уйти. Auto Build этого не делает - он про простоту, не про оптимальность.

Auto Deploy в Kubernetes потребовал подключённого кластера. У клиента кластер уже был, но namespace пришлось настраивать вручную - Auto DevOps создаёт его сам, но права надо выдать заранее. Заняло минут двадцать разбирательств с RBAC.

Review Apps - приятная штука. Каждый feature branch получает временное окружение с реальным URL. Это полезно когда PM хочет посмотреть на фичу до мержа, а не после.

Время от нуля до работающего pipeline

Включение Auto DevOps в настройках проекта - минута. Подключение Kubernetes-кластера в GitLab - минут пятнадцать (если кластер уже есть). Первый прогон pipeline - около двенадцати минут сборки и тестов. Разбор RBAC-прав для деплоя - ещё двадцать минут.

Итого в районе получаса до состояния «CI запущен, тесты прогоняются, деплой на staging работает». Против нескольких дней написания Jenkinsfile с нуля - это принципиально другой масштаб затрат.

SAST в CE: реально полезно

Отдельно про SAST. До 10.0 статический анализ безопасности в GitLab был только в Enterprise Edition. Для небольших команд которые используют Community Edition - недоступно. В 10.0 базовый SAST приехал в CE.

Что он делает: запускает набор анализаторов под язык проекта, результат появляется в интерфейсе merge request как список потенциальных уязвимостей с severity. Это не замена полноценному аудиту безопасности, но как базовый фильтр на CVE в зависимостях и очевидные проблемы в коде - работает.

Найденный gem с CVE мы обновили в тот же день. Без SAST это уехало бы в продуктив незамеченным.

Где Auto DevOps уместен, а где нет

Auto DevOps хорошо работает для стандартных проектов на популярных языках с типичной структурой. Для монорепозиториев, проектов с нестандартным build-процессом или специфическими требованиями к деплою - придётся писать .gitlab-ci.yml вручную. Auto DevOps не конкурирует с ручным CI для зрелых проектов, он закрывает ситуацию «CI нет вообще».

Для команды заказчика это был именно правильный инструмент в правильный момент. Pipeline работает, тесты прогоняются на каждый push, SAST ловит проблемы в зависимостях. Дальше - по мере роста требований - можно выгрузить сгенерированный .gitlab-ci.yml и начать его редактировать. Хороший старт без входного барьера.