Поддержка типовых сценариев изменения: новая функция, исправление дефекта, обновление зависимости, выпуск релиза

Зачем нужен такой сценарий

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

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

по-разному реагировал на новый коммит, запрос на слияние и запуск по тегу;
учитывал, с какой веткой связан конвейер;
запускал нужные стадии и задачи в зависимости от типа изменения;
оставался понятным для команды, даже если сценариев несколько.

Кому особенно полезно

Один процесс — разные точки запуска

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

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

Сценарий 1. Новая функция

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

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

Подробно про управляемую интеграцию через запросы на слияние см. в статье Управляемая интеграция изменений через запрос на слияние.
Подробно про автоматизацию сборки, тестирования и публикации результатов см. в статье Автоматизация сборки, тестирования и публикации результатов через CI/CD.

Сценарий 2. Исправление дефекта

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

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

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

Сценарий 3. Обновление зависимости

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

Для такого сценария особенно важно, чтобы команда не принимала решение “на глаз”, а видела результат проверки в обычном инженерном потоке:

корректно ли проходит сборка;
не ломаются ли тесты;
не меняется ли поведение на этапе интеграции;
достаточно ли текущего маршрута или изменение требует более строгого допуска.

Именно поэтому обновление зависимости в GitFlic должно проходить через тот же управляемый контур, а не восприниматься как “техническая мелочь”, которую можно влить без общего процесса.

Подробно про публикацию результатов проверки и артефактов см. в статье Автоматизация сборки, тестирования и публикации результатов через CI/CD.
Подробно про автоматизацию доставки и промежуточные окружения см. в статье Снижение ручных операций в конвейере доставки (деплоя).

Сценарий 4. Выпуск релиза

Выпуск релиза отличается от предыдущих сценариев тем, что здесь важен не только очередной запуск конвейера, но и формализация самой версии. На этом этапе точкой запуска становится тег, а процесс меняет смысл: теперь команде важно не только проверить изменения, но и оформить выпуск как отдельный результат.

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

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

Как различаются маршруты в зависимости от триггера

Чтобы типовые сценарии не смешивались, важно удерживать простую логику:

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

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

Что получает команда и бизнес

Поддержка типовых сценариев дает несколько прикладных эффектов:

новая функция проходит полный маршрут проверки без ручного усложнения процесса;
исправление дефекта можно провести быстрее, не выходя из управляемого контура;
обновления зависимостей оцениваются по фактическому техническому результату, а не по предположению о “низком риске”;
релизный запуск становится отдельным и понятным маршрутом;
команда работает не с набором разрозненных исключений, а с предсказуемой картой типовых изменений.