Перейти к содержанию

Описание

Download Quality Gate Status Maintainability Rating

Суть проблемы

  • Редактирование неактуальных версий внешних отчетов и обработок.
  • Ручной процесс применения изменений сразу для нескольких информационных баз.
  • Отсутствие контроля за процессом изменения внешних отчетов и обработок.

Цели

  • Хранение внешних обработок в одном месте для различных информационных баз.
  • Использование системы контроля версий.
  • Автоматизированная доставка изменений до информационных баз.

Связь с целями и стратегией

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

Решение

BPMN: процесс разработки внешней обработки

Клонирование репозитория Изменение внешней обработки

Интеграция с внешними хранилищами кода

GitLab

Информация об изменении кода во внешнем хранилище поступает через систему оповещения о событиях (webhooks). Диаграмма последовательности иллюстрирует этот процесс.

GitLab1C.Transmitter1C.Transmitter.BackgroundJobs1C.Transmitter.BackgroundJobsGitLab1C.Transmitter1C.Transmitter.BackgroundJobs1C.EndpointGitLabGitLab1C:Transmitter1C:Transmitter1C:Transmitter:BackgroundJobs1C:Endpoint1C:EndpointGitLab1C.Transmitter1C.Transmitter.BackgroundJobs1C.Transmitter.BackgroundJobswebhookstart job1C:Transmitter:BackgroundJobs200preparerequest files200send filefilestatus
GitLab1C.Transmitter1C.Transmitter.BackgroundJobs1C.Transmitter.BackgroundJobsGitLab1C.Transmitter1C.Transmitter.BackgroundJobs1C.EndpointGitLabGitLab1C:Transmitter1C:Transmitter1C:Transmitter:BackgroundJobs1C:Endpoint1C:EndpointGitLab1C.Transmitter1C.Transmitter.BackgroundJobs1C.Transmitter.BackgroundJobswebhookstart job1C:Transmitter:BackgroundJobs200preparerequest files200send filefilestatus
  1. Для контролируемой ветки в удаленном репозитории на сервере GitLab выполняется некоторое событие.
  2. На сервере GitLab срабатывает webhook в виде запроса по методу POST к HTTP-сервису 1С epf-transmitter.
  3. Веб-сервис epf-transmitter проводит аутентификацию и проверяет данные запроса, переданный в формате json (application/json). Если аутентификация пройдена и данные корректны, то возвращается HTTP-ответ с кодом 200. В противном случае - код ошибки.
  4. Веб-сервис epf-transmitter в фоновом задании обрабатывает тело запроса, подготавливая данные для каждого commit из запроса:
    • с сервера GitLab для каждого commit забирается своя версия файла настроек маршрутизации данных по базам-получателям (по умолчанию, файл.ext-epf.json в корне репозитория);
    • с сервера GitLab для каждого commit забирается своя версия бинарного файла с расширением *.epf, *.erf;
    • данные сохраняются в epf-transmitter для возможности анализа и повторной отправки данных;
    • подготавливаются данные согласно маршрутам доставки;
    • каждый файл в своем фоновом задании отправляется в информационную базу-приемник с сохранением данных о результатах доставки;
Рекомендуемый вариант workflow

Рекомендуемый подход к работе с epf-transmitter заключается в использовании выделенных веток для контролируемой доставки изменений.

  • Основная разработка ведется в ветке master (или develop).
  • Подготовка релиза выполняется релиз-менеджером. Он отбирает готовые к доставке коммиты из master, при необходимости корректирует файл маршрутизации .ext-epf.json и формирует единый, самодостаточный релизный коммит.
  • Доставка изменений инициируется через принудительный push (force push) этого релизного коммита в специализированные ветки, например, deploy-test-srs-XXX, deploy-test и deploy-prod.

Такой подход обеспечивает полный контроль над процессом доставки, сохраняя при этом историю релизов в deploy-* ветках чистой и понятной: один коммит = один деплой.

См. управление доставкой файлов.