Начнём с главного: .gitlab-ci.yml — это декларация намерений, а не сценарий. Мы учим писать конфиг, который читается как документация: каждый job имеет имя, которое отвечает на вопрос «что именно здесь происходит», и переменные вынесены в CI/CD Variables, а не зашиты в файл.

В наших разборах вы найдёте конкретные примеры: как настроить cache для Maven и npm так, чтобы повторные сборки шли за 40 секунд вместо 6 минут; как правильно использовать needs вместо only/except, чтобы не гонять лишние задачи; и как выстроить матрицу сборок под несколько версий Node.js без дублирования конфигурации.

Отдельно разбираем runner-архитектуру: почему shared runners упираются в очередь уже на пятом параллельном job, и когда стоит переходить на Docker executor с изолированными контейнерами. Приводим замеры: на проекте с 1800 модулей переход на собственный runner сократил среднее время поставки с 22 до 9 минут.

Первое правило, которое мы повторяем в каждом материале: не запускайте все тесты на каждый push. Разделяйте на smoke, unit и integration, и прогоняйте их в разных jobs с разной частотой. Smoke-набор из 48 тестов, который покрывает критический путь, должен завершаться за 90 секунд — это наш ориентир.

Второе правило: параллелизация не панацея. На проекте с 3200 integration-тестов мы разбили их на 8 shards с помощью sharding-библиотеки, но получили прирост лишь в 4.2 раза, а не в 8 — из-за contention на общей БД. Разбираем, как изолировать тестовые окружения через Docker volumes и временные инстансы Postgres.

Третье: тестовые артефакты. Скриншоты, логи, trace-файлы OpenTelemetry — всё это нужно сохранять в CI/CD Artifacts с TTL 14 дней. Без этого post-mortem превращается в гадание. Приводим пример из инцидента, когда trace-файл за 3 дня до того помог найти регрессию в 2 строки.