Снижение ручных операций в конвейере доставки (деплоя)

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

Материал не заменяет базовые страницы по CI/CD и запросам на слияние, а показывает, как использовать уже существующие возможности GitFlic в рамках бизнес-кейса снижения ручных операций в доставке изменений.

Какую проблему решает такой подход

Ручной процесс доставки обычно выглядит одинаково:

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

У такого процесса есть несколько типовых проблем:

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

GitFlic позволяет перенести эти действия в управляемый сценарий, где правила задаются один раз и затем одинаково применяются ко всем запросам на слияние.

Как выглядит целевой процесс

В рамках данного сценария процесс строится следующим образом:

Разработчик создает запрос на слияние.
GitFlic автоматически запускает конвейер слияния и, при включенной настройке, конвейер результата слияния.
В конвейере запускаются задачи проверки: автотесты, статический анализ, пользовательские проверки качества.
Логика в gitflic-ci.yaml определяет, в какое окружение выполнять развертывание, исходя из целевой ветки запроса на слияние.
Если условия слияния не выполнены, GitFlic блокирует завершение запроса.
После выполнения всех требований запрос можно завершить вручную или перевести на автоматическое слияние.

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

Предварительная настройка

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

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

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

С подробным описанием настроек можно ознакомиться в статьях Настройка CI/CD и Конвейер.

Шаг 1. Создание запроса на слияние

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

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

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

Подробно форма создания описана в статье Запросы на слияние.

Шаг 2. Автоматический запуск связанных конвейеров

После создания запроса на слияние GitFlic автоматически запускает связанные с ним конвейеры. В карточке запроса можно видеть конвейеры по исходной ветке, конвейер слияния и конвейер результата слияния.

Для бизнес-процесса это важно по двум причинам:

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

В результате запрос на слияние перестает быть только местом обсуждения изменений и становится точкой контроля качества и доставки.

Шаг 3. Автоматические проверки: автотесты и анализ кода

Внутри конвейера можно описать несколько стадий, например:

проверка;
развертывание;
оформление результата.

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

Практический смысл этого шага в том, что команда больше не решает вручную:

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

Все это описывается в gitflic-ci.yaml и выполняется одинаково для каждого нового запроса на слияние.

Шаг 4. Развертывание в разные окружения по целевой ветке

Следующий уровень автоматизации — выбор окружения не человеком, а логикой конвейера.

Например, можно зафиксировать такое правило:

запросы на слияние в develop автоматически разворачиваются в тестовое окружение;
запросы на слияние в release — в приемочное окружение;
запросы на слияние в master — в продуктовое окружение.

Тогда участнику процесса не нужно вручную решать, куда направлять развертывание для каждого конкретного запроса. Это решение уже заложено в конфигурацию.

Такой подход дает два результата:

развертывание становится повторяемым и предсказуемым;
связь «целевая ветка → нужное окружение» перестает существовать только в устной договоренности команды.

Подробно работа с окружениями описана в статье Окружения.

Шаг 5. Пример конфигурации `gitflic-ci.yaml`

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

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

stages:
  - test
  - deploy

Проверка форматирования:
  stage: test
  script:
    - ./gradlew spotsCheck

Автотесты:
  stage: test
  script:
    - ./gradlew maketests

Статический анализ:
  stage: test
  script:
    - ./gradlew staticAnalyze

Развертывание в testing:
  stage: deploy
  script:
    - ./deploy.sh testing
  environment:
    name: testing
    url: https://testing.example.ru
    deployment_tier: testing
  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "develop"

Развертывание в staging:
  stage: развертывание
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.ru
    deployment_tier: staging
  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "release"

Развертывание в production:
  stage: deploy
  script:
    - ./deploy.sh production
  environment:
    name: production
    url: https://app.example.ru
    deployment_tier: production
  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

В этом примере:

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

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

Шаг 6. Настройка запросов на слияние как барьер перед ручными действиями

Автоматизация работает наиболее эффективно тогда, когда GitFlic не просто запускает конвейер, но и не позволяет завершить запрос на слияние до выполнения обязательных требований.

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

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

Эти настройки позволяют превратить запрос на слияние в управляемую контрольную точку, а не в формальный экран перед нажатием кнопки слияния.

Шаг 7. Ответственные для разных целевых веток

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

На практике это позволяет, например:

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

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

Шаг 8. GitFlic сам показывает, чего не хватает до завершения запроса

На странице конкретного запроса GitFlic отображает, какие именно условия уже выполнены, а какие еще блокируют завершение.

Это один из ключевых элементов снижения ручных операций:

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

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

Шаг 9. Дополнительная автоматизация: changelog, служебные сводки, релиз

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

Формирование changelog

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

получать сведения о запросе на слияние;
формировать changelog на основе названия и описания;
сохранять служебную сводку в артефакт или публиковать ее во внешнюю систему.

Создание релиза

Если выпуск версии оформляется формально, можно добавить задачу формирования релиза. Для этого в GitFlic доступна отдельная конфигурация release в gitflic-ci.yaml. Такой сценарий особенно удобен, когда после успешных проверок и развертывания нужно зафиксировать результат поставки в виде релиза проекта.

Пользовательские скрипты

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

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

Шаг 10. Практический результат для команды и бизнеса

При таком подходе GitFlic помогает решить сразу несколько рабочих задач.

Для команды разработки

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

Для руководителя или технического лидера

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

Для сопровождения и эксплуатации

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

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