Идеальный пайплайн: этапы и принципы

Зачем думать про порядок этапов

Пайплайн можно собрать как попало, и он будет работать. Но плохой порядок этапов стоит времени и денег: тяжёлые тесты гоняются до того, как линтер поймал опечатку, образ собирается до того, как упали юнит-тесты. Хороший пайплайн устроен так, чтобы дешёвые проверки отсекали проблему раньше дорогих.

Порядок этапов обычно выглядит так:

lint → build → test → package → deploy

Каждый следующий этап дороже предыдущего, поэтому ломаться выгоднее раньше.

Этапы по порядку

• lint (секунды). Форматирование, статический анализ, очевидные ошибки. Самый дешёвый этап, поэтому первый.
• build (десятки секунд). Компиляция или сборка. Если код не собирается, дальше идти незачем.
• test (минуты). Юнит-тесты, потом интеграционные. Сначала быстрые, потом медленные.
• package (секунды-минуты). Сборка артефакта или образа и публикация в registry.
• deploy. Выкат в окружение. Часто отдельно от остального пайплайна.

Главная идея здесь в том, что дешёвое стоит первым. Линтер за две секунды отсекает опечатку, и тебе не приходится ждать пятиминутные тесты, чтобы узнать о ней.

Куда воткнуть проверки безопасности

Часто «scan» рисуют одним этапом где-то в середине. Это ошибка: под словом scan прячутся разные проверки, и им нужны разные моменты пайплайна.

Скан зависимостей и поиск утёкших секретов работают по исходникам. Ни собранный бинарь, ни образ им не нужны, а значит их место рядом с линтером — до сборки. Смысл простой: если в коммит уехал приватный ключ, узнать об этом надо через двадцать секунд, а не после пяти минут тестов. То же с зависимостью, у которой критичная CVE — собирать образ на ней незачем.

Скан образа проверяет то, чего в исходниках нет: базовый слой, системные пакеты, конфигурацию пользователя. Пока образа не существует, сканировать нечего, поэтому проверка идёт после сборки образа — и до push в registry. Иначе дырявый образ уже лежит в реестре и кто-то успевает его выкатить.

Собранный порядок:

lint + scan:deps + scan:secrets   ← по исходникам, до сборки
        ↓
build → test
        ↓
package: сборка образа → scan:image → push
        ↓
deploy

Fail-fast

Fail-fast значит остановиться на первой же ошибке, а не гнать пайплайн до конца. Упал build, и нет смысла запускать тесты: тестировать нечего. GitLab CI и большинство систем останавливают пайплайн на первом упавшем этапе сами.

Внутри одного этапа полезно наоборот: запустить параллельные проверки и показать сразу все провалы, чтобы не чинить их по одной. Линтер, проверка типов и аудит зависимостей могут идти разом.

Быстрая обратная связь

Главная ценность CI в том, как быстро разработчик узнаёт о проблеме. Пайплайн на 40 минут, который сообщает об опечатке в самом конце, почти бесполезен: контекст уже потерян. Поэтому за временем пайплайна следят и сокращают его.

Что ускоряет:

• кеш зависимостей и слоёв (не качать одно и то же каждый раз),
• параллельные job вместо последовательных,
• быстрые тесты на каждый push, медленные и e2e реже (ночью или перед релизом).

Ориентир: основной пайплайн на push должен укладываться в несколько минут. Всё, что дольше, выносят в отдельные расписания.

Где граница деплоя

lint → build → test → package обычно идёт автоматически на каждый push. А вот deploy отделяют. В прод катят либо по тегу, либо по ручному подтверждению (manual gate), либо автоматически, но только из защищённой ветки. Эту границу разбирает следующий урок про стратегии выката.

Что важно запомнить

Дешёвые проверки стоят первыми: линтер до сборки, сборка до тестов, тесты до упаковки. Так проблема ловится раньше и дешевле.

Fail-fast останавливает пайплайн на первом провале, но внутри этапа проверки полезно гонять параллельно и показывать все провалы сразу.

Проверки безопасности разносят по пайплайну: зависимости и секреты сканируют по исходникам до сборки, образ — после сборки образа и до push в registry.

Ценность CI в скорости обратной связи. Основной пайплайн держат коротким, тяжёлое выносят в отдельные расписания. Деплой отделяют от остального и ставят за тег или подтверждение.

В следующем уроке разберём стратегии выката: blue-green, canary и rolling.