Где теряется время разработчика без CI/CD, автотестов и дев-стенда

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

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

Термины

CI (continuous integration) — автоматическая сборка и проверка каждого изменения, отправленного в репозиторий.

CD (continuous delivery) — автоматическая доставка проверенной сборки на стенд или в продуктивную среду.

Пайплайн — последовательность шагов, описанная в файле внутри репозитория: сборка, тесты, анализ кода, выкатка. Пайплайн запускается сам при каждом изменении. Его исполняют GitLab CI, GitHub Actions, Jenkins и аналогичные системы.

SAST (static application security testing) — поиск уязвимостей в исходном коде без его запуска.

SCA (software composition analysis) — проверка сторонних библиотек по базам известных уязвимостей.

Дев-стенд — среда, в которой работает актуальная версия приложения из основной ветки. Тестировщик, менеджер и заказчик смотрят на нём результат до релиза.

1. Ручная сборка и выкатка

Ручная выкатка состоит из десяти–двадцати шагов: получить код, собрать, скопировать файлы на сервер, применить миграции базы данных, перезапустить сервисы, проверить результат. Одна выкатка занимает от 20 до 60 минут. Последовательность шагов обычно знают один или два человека, и остальные разработчики ждут, пока эти люди освободятся.

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

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

В пайплайне те же шаги записаны в файле и выполняются одинаково при каждом запуске. Выкатку запускает любой член команды. Откат выполняется повторным запуском пайплайна для предыдущей версии.

2. Ручная проверка вместо автотестов

Без автотестов разработчик после каждого изменения проверяет руками собственную задачу и соседние функции, которые могло затронуть изменение. Всю систему перед релизом никто не проверяет: полная ручная проверка занимает дни.

Ошибку в непроверенной функции обнаруживает пользователь. От появления ошибки до сообщения о ней проходит от нескольких дней до нескольких недель. За это время разработчик перешёл к другим задачам. Для исправления он заново читает собственный код, восстанавливает ход решения и ищет изменение, которое вызвало ошибку. Исправление той же ошибки через десять минут после коммита занимает меньше времени, потому что разработчик помнит код.

Автотесты сокращают этот интервал до длительности пайплайна. Полное покрытие для этого не требуется. Основной эффект дают тесты на сценарии, которые приносят выручку: регистрация, оформление заказа, оплата.

3. Отсутствие дев-стенда

Без стенда результат работы видит только сам разработчик на своём компьютере. Конфигурация его компьютера отличается от конфигурации сервера: другие версии библиотек, другие данные, другие настройки. Часть ошибок проявляется только на сервере, то есть после релиза.

Тестировщик и менеджер получают доступ к результату после выкатки в продуктивную среду. Замечания к интерфейсу и логике поступают, когда функция уже доступна пользователям. Каждое замечание означает повторный цикл разработки и ещё одну выкатку.

Один общий стенд на команду решает задачу частично. Разработчики занимают его по очереди, и выкатка одной ветки перезаписывает изменения предыдущей. Текущая практика — отдельная временная среда для каждого запроса на слияние (preview environment, в GitLab — review app). Пайплайн создаёт её при открытии запроса, публикует ссылку в обсуждении и удаляет среду после слияния. Проверяющий открывает ссылку и видит именно то изменение, которое проверяет.

4. Поздно найденные уязвимости

Без анализа кода в пайплайне уязвимости находят в трёх случаях: на внешнем аудите, при проверке службой безопасности заказчика и после инцидента. К этому моменту на уязвимом коде уже построены другие функции. Исправление затрагивает их все и требует повторной проверки.

Отдельный случай — пароль или ключ доступа, попавший в репозиторий. Удалить его коммитом нельзя, он остаётся в истории. Приходится перевыпускать ключ, обновлять его во всех системах, где он использовался, и проверять журналы доступа за весь период утечки. Это один–два рабочих дня.

Автоматическая проверка в пайплайне включает три части:

• поиск секретов (gitleaks, встроенные средства GitLab и GitHub) блокирует коммит с ключом до его попадания в основную ветку;
• SCA (Trivy, osv-scanner, Dependabot, Renovate) сообщает об уязвимой библиотеке и создаёт запрос на обновление версии;
• SAST (Semgrep, CodeQL, анализаторы GitLab) находит в коде небезопасные конструкции: подстановку пользовательского ввода в SQL-запрос, отключённую проверку сертификата, небезопасную десериализацию.

Разработчик видит замечание в запросе на слияние через несколько минут после отправки кода и исправляет его в рамках той же задачи. Этот подход называется shift left: проверка безопасности переносится с этапа перед релизом на этап написания кода.

5. Долгоживущие ветки

Без быстрой автоматической проверки разработчики объединяют код редко. Ветка существует две–три недели и за это время расходится с основной. Слияние вызывает конфликты, разрешение конфликтов занимает часы. Ошибки, внесённые при разрешении конфликтов, остаются незамеченными, потому что автотестов нет.

Практика trunk-based development предполагает ветки, которые живут не дольше одного–двух дней, и слияние в основную ветку малыми порциями. Незавершённые функции при этом закрываются переключателями (feature flags) и недоступны пользователям. Эта практика работает только при наличии пайплайна: каждое слияние должно быть проверено автоматически за минуты.

6. Ожидание и переключение между задачами

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

Модель DevEx (Нода, Стори, Форсгрен, Грайлер, 2023) описывает продуктивность разработчика тремя факторами: скорость обратной связи, когнитивная нагрузка и возможность непрерывной сосредоточенной работы. Отсутствие автоматизации ухудшает все три. Обратная связь приходит через дни. Порядок ручных операций приходится держать в памяти. Рабочий день дробится ожиданиями.

Влияние ИИ-ассистентов

С ИИ-ассистентом разработчик пишет код быстрее, и количество изменений в единицу времени растёт. Скорость ручной проверки и ручной выкатки при этом прежняя. Очередь непроверенных изменений увеличивается, и срок поставки определяется уже проверкой и выкаткой.

Отчёты DORA за 2024 и 2025 годы фиксируют эту зависимость. Рост использования ИИ сопровождается снижением стабильности поставки в командах без автоматических проверок. Вывод отчёта 2025 года: ИИ усиливает уже существующие свойства процесса разработки, как сильные, так и слабые. Поэтому автоматические тесты и анализ кода следует настраивать до массового внедрения ассистентов или одновременно с ним.

Как измерить потери

Измерение занимает одну рабочую неделю. Каждый разработчик записывает в общую таблицу время по пяти категориям:

1. ручная сборка и выкатка;
2. ручная проверка перед релизом;
3. ожидание стенда, выкатки или проверяющего;
4. исправление дефектов, найденных после релиза;
5. разрешение конфликтов слияния.

Пример для команды из пяти разработчиков:

28 часов составляют 14% недельного фонда времени команды (200 часов). При стоимости часа разработчика 2 500 рублей это 70 000 рублей в неделю, или около 300 000 рублей в месяц. Цифры в примере условные. Таблица с вашими данными даёт сумму, с которой сравнивается стоимость внедрения автоматизации.

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

Порядок внедрения

Шаги расположены по убыванию отношения результата к трудозатратам. Каждый шаг даёт результат без следующих.

1. Пайплайн со сборкой и линтером на каждый запрос на слияние. Это один файл в репозитории: .gitlab-ci.yml или каталог .github/workflows. Срок — один–два дня. С этого момента несобирающийся код не попадает в основную ветку.
2. Автоматическая выкатка основной ветки на дев-стенд. Срок — от двух дней до недели, в зависимости от того, насколько описана конфигурация сервера.
3. Автотесты на три–пять сценариев, приносящих выручку. Тесты добавляются в пайплайн как обязательный шаг. Далее действует правило: каждый дефект, найденный после релиза, закрывается вместе с тестом, который его воспроизводит.
4. Поиск секретов и SCA. Оба инструмента подключаются за несколько часов и дают мало ложных срабатываний.
5. SAST с ограниченным набором правил. Анализатор с полным набором правил выдаёт сотни замечаний, и команда перестаёт их читать. Рабочая схема: включить правила высокой критичности, блокировать слияние только по ним, остальные правила добавлять после разбора существующих замечаний.
6. Временные среды для запросов на слияние. Этот шаг требует контейнеризации приложения, поэтому стоит последним.
7. Выкатка в продуктивную среду из пайплайна с ручным подтверждением и откатом одной командой.

Длительность пайплайна следует удерживать в пределах десяти минут. При более долгом пайплайне разработчик снова переключается на другую задачу на время ожидания. Основные средства сокращения — кэширование зависимостей и параллельный запуск тестов.

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

Как проверить результат

Результат оценивают по метрикам DORA. Все они вычисляются из данных системы контроля версий и пайплайна:

• частота выкаток в продуктивную среду;
• время поставки изменения — от коммита до работы в продуктивной среде;
• доля неудачных выкаток — выкатки, после которых потребовался откат или срочное исправление;
• время восстановления после неудачной выкатки;
• доля незапланированных переделок — выкатки, сделанные для исправления дефектов.

Значения фиксируют до начала внедрения и сравнивают раз в квартал. Через квартал повторяют недельный замер из раздела «Как измерить потери». Разница в часах, умноженная на стоимость часа, даёт экономию в рублях.

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

Настройка пайплайна, автотестов, анализа кода и стендов входит в мои услуги. Для оценки объёма работ нужны доступ к репозиторию и описание текущего порядка выкатки.