Автоматизация процессов разработки ПО: конвейер от коммита до прода

Автоматизация процессов разработки ПО это перевод повторяющихся шагов между коммитом и продакшеном на конвейер, который запускается сам: сборка, тесты, статический анализ, публикация артефакта, выкатка и откат. Речь не о том, кто пишет код, а о том, что происходит с кодом после нажатия push. Сюда не относятся ИИ-помощники, пишущие код за разработчика, service desk и контроль качества продукции на производстве. Ниже лимиты платформ, ставки за минуту сборки, состав пайплайна, инструменты тестирования и метрики, по которым видно, работает конвейер или имитирует работу.

Ветвление и код-ревью: с чего начинается автоматизация разработки ПО

Автоматизация разработки ПО начинается не с покупки CI-сервера, а с модели ветвления. Если ветка живёт три недели, конвейер не спасёт: конфликты слияния съедят выигрыш от автоматических тестов.

Исследование DORA по практике trunk-based development даёт три проверяемых ориентира: в репозитории приложения держится три или меньше активных веток, ветка сливается в основную минимум раз в день, время её жизни измеряется часами, а не днями. Отдельно оговорено отсутствие code freeze и выделенных фаз интеграции.

Технический минимум: защита основной ветки, зелёный статус проверок перед слиянием, минимум один аппрув, CODEOWNERS с ответственными за каталоги. Настраивается в GitHub, GitLab, GitFlic и GitVerse без единой строки кода и работает ещё до появления первого пайплайна.

CI CD: три практики, которые постоянно путают

За аббревиатурой CI CD прячутся три разные вещи. Их подменяют одну другой, а потом удивляются, что «внедрили CI/CD», а релиз всё равно собирает человек руками.

• Continuous Integration: код попадает в общую ветку и автоматически собирается и тестируется при каждом изменении, ошибка находится за минуты после коммита.
• Continuous Delivery: артефакт доводится до состояния «готов к выкатке» и разворачивается в тестовой среде, выкатку в прод запускает человек кнопкой.
• Continuous Deployment: тот же конвейер без кнопки, каждое прошедшее проверки изменение уезжает в прод само.

Большинству команд достаточно второго варианта. Третий требует зрелых тестов, наблюдаемости и автоматического отката, иначе превращается в способ быстрее ломать прод.

Из чего состоит CI CD пайплайн: стадии и порядок

Типовой ci cd пайплайн разбит на стадии, каждая следующая запускается после зелёной предыдущей. Порядок продиктован стоимостью: дешёвые и быстрые проверки первыми.

Стадия	Что делает	Ориентир по времени
Checkout и кэш	Код и кэш зависимостей	секунды
Lint	Стиль и очевидные ошибки без запуска кода	до минуты
Build	Бинарник, пакет или контейнерный образ	1–5 минут
Юнит-тесты	Отдельные функции и классы	1–5 минут
Анализ и секреты	SAST, поиск токенов, проверка зависимостей	2–10 минут
Интеграционные тесты	Связка с БД, очередями, внешними API	5–15 минут
Публикация артефакта	Образ в реестр с тегом версии	1–3 минуты
Deploy на тест	Разворачивание и smoke-тесты	2–10 минут
E2E-тесты	Сценарии через браузер на живом стенде	5–30 минут
Deploy в прод	Выкатка стратегией и проверка здоровья	минуты

Практическое правило: обратная связь на pull request приходит за 10 минут, остальное уходит в ночной прогон по расписанию. Медленный конвейер разработчики обходят, и он перестаёт защищать.

Платформы: GitHub Actions, GitLab CI, Jenkins и российские сервисы

Выбор решается тем, где уже лежит код. Разница в лимитах и в том, как быстро бесплатный тариф упирается в потолок.

GitHub Actions. Публичные репозитории на стандартных раннерах и любые self-hosted раннеры бесплатны. Для приватных квота зависит от плана: Free 2000 минут в месяц и 500 МБ хранилища, Pro 3000 минут и 1 ГБ, Team 3000 минут и 2 ГБ, Enterprise Cloud 50 000 минут и 50 ГБ. Хранилище артефактов делится с GitHub Packages, кэш идёт отдельной квотой 10 ГБ на репозиторий. Сверх квоты работают ставки за минуту: Linux 2-core x64 0,006 USD, Windows 2-core 0,010 USD, macOS 3-4 core 0,062 USD, минуты округляются вверх до целой. Минута под macOS дороже линуксовой примерно в десять раз, и это первое, что стоит проверить в счёте.

Жёсткие лимиты Actions: задача на раннере GitHub не более 6 часов, на self-hosted до 5 дней, весь workflow run 35 дней, матрица 256 задач, ожидание в очереди 24 часа, файл workflow 500 КБ, повторный запуск не более 50 раз. Логи и артефакты хранятся 90 дней, срок настраивается на уровне репозитория, организации или артефакта.

GitLab CI. На GitLab.com пространство имён уровня Free получает 400 вычислительных минут в месяц, платные тарифы больше. Списание идёт по формуле «длительность задачи в секундах / 60 × коэффициент», коэффициент зависит от машины: Linux x86-64 small 1, medium 2, large 3, xlarge 6, 2xlarge 12; Linux с GPU medium 7; macOS M1 6, M2 Pro 12. То есть 400 минут на машине medium это фактически 200 минут работы. Артефакты живут по ключу artifacts:expire_in, удаляются почасовым cron-заданием, значение never отключает удаление.

Jenkins. Свободный сервер на своём железе, платы за минуты нет, платите за администрирование. Релизы: раз в 12 недель сообщество выбирает базовую версию линии Long-Term Support, затем выходят три минорных релиза с шагом в 4 недели, релиз-кандидат за две недели до каждого. Для регулируемых контуров это предсказуемое окно обновлений, для маленькой команды лишний сервер.

Российские платформы. GitFlic заявляет запись №15861 в реестре российского ПО от 09.12.2022, бесплатный SaaS-тариф даёт репозиторий до 4 ГБ, коммит до 100 МБ, приватные проекты до 5 человек включительно, CI/CD и реестр контейнеров и пакетов. Тариф «Компания» от 750 ₽ в месяц за пользователя, self-hosted Community Edition бесплатен, редакция Pro с SAST и защищёнными окружениями от 243 000 ₽ в год. GitVerse хранит конвейеры в каталоге .gitverse/workflows/, синтаксис YAML в целом совместим с GitHub Actions, существующие workflow переносятся почти без правок. Раннер называется act_runner, параллелизм задаётся параметром capacity, сборка образов на облачном раннере делается через kaniko.

Артефакты, кэш и реестры: где конвейер начинает стоить денег

Счёт за CI растёт не из-за минут сборки, а из-за хранения. У GitHub оно считается почасово и накапливается: если 10 ГБ артефактов пролежали 10 дней и были удалены на одиннадцатый, в счёт попадут 2400 ГБ-часов. Удаление прекращает дальнейшее начисление, но не отменяет уже начисленное.

1. Задать срок хранения артефактам: промежуточным от 1 дня до недели, релизным отдельную политику.
2. Не класть в артефакты то, что пересобирается: node_modules, виртуальные окружения, кэш компилятора. Для них есть механизм кэша.
3. Хранить образы в реестре с политикой очистки. Harbor это открытый реестр уровня Graduated в CNCF: ролевая модель, сканирование на уязвимости, подпись, текущая ветка 2.15.
4. Тегировать образы по хэшу коммита, а не только latest: иначе откат превращается в гадание, какая сборка сейчас в проде.

Пирамида тестов и инструменты автоматизации тестирования

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

• pytest для Python: фикстуры, параметризация, маркеры, перезапуск упавших тестов, большой каталог плагинов, отдельный раздел документации про flaky-тесты.
• Playwright: E2E-фреймворк с раннером, ассертами, изоляцией и параллелизмом в одной поставке. Поддерживает Chromium, WebKit и Firefox на Windows, Linux и macOS, в headless и headed режимах, с эмуляцией Chrome на Android и Mobile Safari. Для CI важны штатные sharding, retries и trace viewer.
• Selenium: инструмент того же класса на стандарте W3C WebDriver, Grid распределяет прогон по машинам и браузерам. Разумен там, где нужен зоопарк браузерных версий или уже есть большая база тестов.

Отдельный вопрос это нестабильные тесты. Тест, падающий один прогон из двадцати, дороже отсутствующего: команда перестаёт читать красный статус. Правило это карантин: такой тест выносится из блокирующего набора с задачей на исправление и сроком, а не отключается навсегда. Как ИИ подключается к написанию тестов, разобрано в материале про лучшие ИИ-агенты для программирования.

Статический анализ, секреты и уязвимости: порог качества

Проверки качества стоит делать блокирующими сразу: они дешёвые и находят то, что человек на ревью пропускает.

SonarQube Community Build бесплатен и открыт: статический анализ для 21 языка и фреймворка (Java, JavaScript, TypeScript, Python, C#, Go, Kotlin, PHP, Terraform, Docker, Kubernetes и другие), базовая детекция секретов, учёт технического долга, интеграция с GitHub, GitLab, Bitbucket и Azure DevOps, более 50 плагинов сообщества. Платная Developer Edition добавляет анализ веток и pull request, taint-анализ для поиска инъекций и детекцию секретов по 400+ паттернам с 340+ правилами. Граница проходит по анализу pull request: в бесплатной версии результат приходит на весь проект, а не на конкретное изменение.

Trivy закрывает вторую половину: сканирует образы, файловые системы, репозитории, образы виртуальных машин, кластеры Kubernetes и SBOM, а по типам находок отдаёт уязвимости, ошибки конфигурации, секреты и лицензии. Из IaC понимает Terraform, Helm, Kubernetes, Docker, CloudFormation, Azure ARM и Ansible. Для утёкших токенов в истории репозитория добавляют gitleaks.

Порог настраивается по правилу «новый код»: не вычищать весь долг разом, а запретить ухудшение, то есть новые строки покрыты тестами и без критичных находок. Единственный вариант, который приживается на старом проекте.

Инфраструктура как код и лицензионный риск

Пока тестовая среда собирается руками, «у меня работает» побеждает любой пайплайн. Описание окружения кодом снимает это: среда лежит в репозитории и одинакова у всех.

Здесь нюанс, который дорого стоит тем, кто строит на этом стеке продукт. Terraform начиная с версии 1.6.0 распространяется под Business Source License 1.1: лицензиар IBM Corp., производственное использование разрешено, но запрещено предлагать продукт третьим лицам на хостинговой или встроенной основе, если он конкурирует с платными версиями. Change Date наступает через четыре года после публикации версии, дальше действует MPL 2.0. Ответ сообщества это OpenTofu под управлением Linux Foundation: drop-in замена Terraform, версия 1.12.0, более 3900 провайдеров и 23 600 модулей. Для внутренней инфраструктуры разница почти нулевая, для продаваемого продукта принципиальная.

Выкатка и откат: что делать, когда релиз пошёл не так

Автоматизация без отката это ускоритель аварии. Минимальный набор.

• Blue-green: два одинаковых контура, трафик переключается на новый после проверки здоровья, откат это переключение обратно за секунды. Цена в двойных ресурсах.
• Canary: новая версия получает небольшую долю трафика, метрики ошибок сравниваются с базовой, при росте срабатывает автоматический откат. Требует наблюдаемости.
• Фичефлаги: код уезжает в прод выключенным, включается и выключается без пересборки. Развязывает выкатку и релиз функции.
• Миграции БД: только совместимые вперёд и назад. Добавили колонку и пишем в обе, потом переключили чтение, потом удалили старую, тремя релизами вместо одного.

Обязательное упражнение это репетиция отката на тестовом контуре с секундомером. Ориентир простой: пока откат занимает больше четверти часа, автоматический деплой в прод включать рано.

Метрики DORA: пять чисел вместо ощущений

Оценивать конвейер по количеству настроенных пайплайнов бессмысленно. DORA описывает пять метрик в двух группах.

Группа	Метрика	Что измеряет
Пропускная способность	Change lead time	Время от коммита в систему контроля версий до выкатки в прод
Пропускная способность	Deployment frequency	Число выкаток за период или интервал между ними
Пропускная способность	Failed deployment recovery time	Время восстановления после неудачной выкатки
Нестабильность	Change fail rate	Доля выкаток, потребовавших немедленного вмешательства
Нестабильность	Deployment rework rate	Доля незапланированных выкаток, вызванных инцидентом в проде

Группы читаются только вместе: рост частоты выкаток при растущей доле сбоев это не улучшение, а разгон производства брака. Метрика восстановления заменила привычный MTTR, а rework rate добавлена как признак того, что команда чинит прод внеплановыми релизами. Числа снимаются из API платформы CI: даты коммитов, времена запуска деплой-задач и их статусы дают четыре метрики из пяти без ручного учёта.

План на 30 дней: в каком порядке внедрять

1. Дни 1–3. Защита основной ветки, обязательный ревьюер, CODEOWNERS. Ноль строк кода, эффект сразу.
2. Дни 4–7. Пайплайн из двух стадий, линтер и сборка на каждый pull request, цель это зелёный статус за 5 минут.
3. Дни 8–14. Юнит-тесты, кэш зависимостей, публикация артефакта с тегом по хэшу коммита.
4. Дни 15–21. Сканеры: анализ нового кода, поиск секретов, проверка зависимостей и образа, в предупреждающем режиме.
5. Дни 22–26. Автоматический деплой в тестовую среду, smoke-тесты после него, описание среды кодом.
6. Дни 27–30. Репетиция отката с секундомером, блокирующий порог качества, снятие первых значений метрик как базовой линии.

Прод в план не входит намеренно: автоматическую выкатку включают после того, как шесть пунктов отработали хотя бы месяц без сюрпризов.

Частые вопросы

Сколько стоит запустить CI/CD с нуля

На GitHub Free приватному репозиторию доступно 2000 минут в месяц и 500 МБ хранилища, на GitLab.com уровня Free 400 вычислительных минут. Сверх квоты минута Linux-раннера GitHub стоит 0,006 USD, тысяча минут около 6 USD. Основной расход это не платформа, а инженерное время.

Что выбрать: облачные раннеры или свои

Свои раннеры бесплатны по минутам и снимают лимит в 6 часов на задачу, на self-hosted он равен 5 дням. Взамен появляется обязанность обновлять и защищать машины. Порог проходит там, где сборки стабильно выходят за квоту и упираются в производительность двухъядерного раннера.

Обязательно ли уходить с Terraform на OpenTofu

Для внутренней инфраструктуры нет, BUSL 1.1 разрешает производственное использование. Проверять лицензию нужно, если вы предлагаете третьим лицам продукт, конкурирующий с платными версиями: такой сценарий запрещён до Change Date, то есть четыре года после публикации версии.

Сколько браузерных тестов держать в пайплайне

Столько, чтобы блокирующий набор укладывался в 10 минут обратной связи на pull request. Остальные сценарии Playwright уходят в ночной прогон с шардингом. Тест, падающий без изменений кода, отправляется в карантин с задачей на исправление.

С какой метрики начинать измерение

С change lead time, времени от коммита до прода. Оно считается по данным из API платформы CI и сразу показывает узкое место: длинное ревью, медленная сборка или ручная выкатка. Следом идёт change fail rate, чтобы ускорение не оказалось разгоном брака.