Управление доставкой файлов

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

Общая концепция

• Ветка master используется для основной разработки и хранения финального кода.
• Ветки deploy-* (например, deploy-test-srs-XXX, deploy-test, deploy-prod) используются исключительно как триггеры для запуска доставки. История в этих ветках ведется в виде "один коммит — один деплой".

Преимущества подхода

Этот рабочий процесс, основанный на принудительном обновлении (force push) веток доставки, имеет несколько ключевых преимуществ:

• Полный контроль: Релиз-менеджер полностью контролирует состав релиза, вручную отбирая коммиты для доставки. Разработка в master не приводит к автоматическому развертыванию.
• Безопасность: Риск случайной отправки не протестированных изменений минимизируется. Благодаря защите веток, только авторизованные пользователи (например, с ролью Maintainer) могут инициировать деплой.
• Простота: Процесс максимально упрощен для разработчиков. Им не нужно создавать Merge Request'ы или разрешать конфликты слияния для деплоя — достаточно следить за качеством своих коммитов в master.
• Прозрачность: История deploy-* веток становится чистым и понятным логом развертываний. Каждый коммит представляет собой атомарный релиз, что значительно упрощает аудит и возможный откат изменений.

Шаг 0: Настройка репозитория (роль: DevOps/TL)

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

1. Создайте ветки для деплоя, если они еще не существуют.

   # Создаем ветку для тестовой среды
   git checkout -b deploy-test master
   # Создаем ветку для продуктивной среды
   git checkout -b deploy-prod master
   # Отправляем ветки на сервер
   git push origin deploy-test deploy-prod
   

2. Защитите deploy-* ветки в GitLab. Это ключевой шаг, который позволяет использовать упрощенный workflow без риска случайных действий.

   • Перейдите в настройки репозитория: Settings → Repository → Protected branches.
   • Для каждой deploy-* ветки установите следующие права:
     • Allowed to merge: No one (Никто).
     • Allowed to push and merge: выберите роль, ответственную за релизы (например, Maintainers).
     • Allowed to force push: Включите этот переключатель.

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

Шаг 1: Процесс разработки (роль: Разработчик)

Разработчики ведут работу в master или своих feature-ветках. В идеальном сценарии каждый коммит с изменением обработки (*.erf, *.epf) также содержит и соответствующее правило в .ext-epf.json.

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

Шаг 2: Подготовка и деплой релиза (роль: Релиз-менеджер)

Этот процесс выполняется ответственным за релиз и не требует создания Merge Request'ов или решения конфликтов.

1. Определите коммиты для релиза. Просмотрите историю master и выберите один или несколько коммитов, готовых к доставке. Например, a1b2c3d и e4f5g6h.

2. Создайте локальную ветку-"черновик" от текущего состояния deploy-test.

   # Получаем все свежие изменения с сервера
   git fetch origin
   
   # Создаем ветку для подготовки релиза от актуального состояния deploy-test
   git checkout -b release-candidate origin/deploy-test
   

3. Перенесите и объедините коммиты.

   • Перенесите нужные коммиты из master в вашу ветку release-candidate.

     # Переносим коммиты с новыми обработками
     git cherry-pick a1b2c3d e4f5g6h
     

   • Подготовьте файл маршрутизации. Откройте .ext-epf.json, проверьте и при необходимости добавьте/измените правила для всех обработок, входящих в релиз. Зафиксируйте эти изменения отдельным коммитом.

     git add .ext-epf.json
     git commit -m "chore: Скорректирована маршрутизация для релиза"
     

   • "Схлопните" все подготовительные коммиты в один. Это ключевой шаг для создания чистого релизного коммита. Если вы перенесли 2 коммита и сделали 1 коммит для маршрутизации, то команда будет выглядеть так:

     # Запускаем интерактивный rebase для последних 3 коммитов
     git rebase -i HEAD~3
     

   • В открывшемся редакторе у первого коммита оставьте pick, у второго замените pick на s (squash).
   • Сохраните файл. В следующем окне напишите единое, осмысленное сообщение для всего релиза, например: feat(F1C-123, F1C-456): Добавлен отчет по продажам и обработка прайс-листа.
   • В результате в вашей ветке release-candidate появится один новый, чистый коммит поверх истории deploy-test.

4. Выполните деплой на тест.

   # Принудительно обновляем ветку deploy-test на сервере до состояния нашего релизного коммита
   git push origin release-candidate:deploy-test --force
   

   Эта команда инициирует push-событие, на которое среагирует epf-transmitter и доставит изменения.

5. Деплой на продуктив. После успешного тестирования процесс повторяется для deploy-prod.

   # Принудительно обновляем ветку deploy-prod до состояния протестированного релиза
   git push origin release-candidate:deploy-prod --force