Jenkins pipeline для автоматизации процесса переноса схем между различными средами Schema Registry

Общая задача:

Jenkins pipeline, который представляет собой комплексную систему автоматизации схем Kafka Schema Registry между окружениями

(dev → test → preprod → prod) с использованием pull request workflow, при котором исключены человеческие ошибки.

Рис1. Диаграмма компонентов

Архитектура и принцип работы

Основное решение — запуск, инициирующий перенос схем с параметрами:

1. webhook-driven — BitBucket отправляет webhook об изменении статуса PR;

2. ручной запуск может производиться в двух состояниях: — Full Pipeline — полный цикл переноса схем; — TESTS ONLY — процессор выполнения JUnit-тестов.

Ключевые компоненты

· EventTrigger — блок обработки BitBucket webhook. · Файловая синхронизация для координации между процессами. · SSH-подключения к серверам. · Email-уведомления по всем этапам процесса.

Общая схема архитектуры

Рис2. Общая схема архитектуры

Файловая синхронизация

Файловая синхронизация в процессе CI/CD pipeline организовывает взаимодействие компонент (BitBucket, Jenkins, SSH-сервера).

Для синхронизации всех процессов используется структура файлов.

Для каждого PR в ветке создаётся временный текстовый файл со статусом

(pr-status-to-env-$target_env-$subject-$build.txt)

и сохраняется в каталоге:

/var/lib/jenkins/slave/workspace/DataFlow/schemas-registry-ci-cd/

Файл содержит текущее состояние PR. Возможные значения:

· OPEN, · MERGED, · DECLINE.

При создании ветки и PR pipeline пишет статус OPEN в файл.

Когда приходит изменение статуса через webhook (когда webhook ловит событие merge или decline PR), pipeline обновляет значение статуса в своём файле: MERGED или DECLINED — в зависимости от статуса PR.

Основной pipeline на основании нового статуса либо продолжает релиз (MERGED), либо завершает процесс (если DECLINED).

Рис3. Диаграмма жизненного цикла файла

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

Асинхронность — внешние события (merge/decline PR) могут происходить в любое время. Jenkins-триггер просто проверяет файл и не блокирует ресурсы. Интеграция с внешними системами — webhook легко обновляет статус в файле. Изоляция — каждая pipeline работает со своими файлами и не мешает другим процессам.

Рис4. Работа с PR

Поведение webhook и обработка статусов

Как уже было сказано, при получении webhook от BitBucket,если PR pipeline изменил статус в файле — начинается соответствующий блок работы.

Если процесс был запущен вручную (инициализация pipeline вручную, без webhook),

PR есть или создаётся вручную. Далее pipeline выполняет проверку совместимости: проверяет корректность схем относительно Schema Registry, наличие предыдущих версий, а также проверяет валидацию схем.

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

Логика определения статусов

· Имя всех файлов статуса по шаблону: *pr-status-to-env-${env}-${subject}-.txt**

· Для каждого файла известно имя ветки и PR ID.

· Статус обновляется через BitBucket API: POST /pull-requests/{id}/decline

· После закрытия PR (POST) pipeline удаляет ветку (git push — delete).

Инициализация: сохранение файла и запись в него статуса OPEN

Это позволяет pipeline начать течение ревьювера и улучшить интеграцию с BitBucket webhook (новые события PR сразу подхватываются).

Получение ранних полей инициированного build

Необходимо для git commit, email-уведомлений и отслеживания PR.

Валидация input-параметров

Если при инициализации пользователь ввёл все нужные данные, pipeline продолжает работу. Если каких-то параметров не хватает — пользователь получает уведомление, а pipeline ожидает новые данные.

Эта часть помогает исключить ошибки ввода или нехватку параметров.

Перенос схемы

Рис5. Перенос схемы

Проверка схемы

При помощи SSH pipeline подключается к серверу Shema Registry и получает оттуда:

o schema o schemaType (AVRO or JSON) o compatibility level

Это позволяет проверить, что схема действительно существует и она корректна. Если схема не существует на source env — пользователь получает уведомление

Рис6. Проверка схемы

Валидация схемы

Pipeline валидирует полученную схему. При помощи Schema-registry API проверяет совместимость текущей схему с уже существующей на целевом env схемой.

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

Работа с BitBucket

Pipeline создает новую ветку и инициирует PR. · Pattern → to-env-${env}-${subject}-${buildID}

Благодаря этому история изменения схем фиксируется в BitBucket и запускается процесс ревью схемы. Ревьюверу отправляется письмо с сылкой на PR.

Ожидание PR резолюции

Pipeline замирает на 7 дней, периодически проверяя статус PR в файле. Если статус меняется — pipelineпродолжит работу. Если в течении 7 дней изменений не произойдет — pipeline закончит работу

Рис7. Ожидание резолюции для PR

Post PR Action

В зависимости от результата PR:

· Merged — pipeline выставляет compatibility схемы и регистрирует схему на целевой ветке на сервереschema-registry · Declined — pipeline отправляет пользователю уведомление и прекращает работу

Рис8. Полный цикл работы с PR

Delete branch

После деплоя ветки (или его отмены), pipeline проверяет наличие “отработавшей” ветки в BitBucket. Если ветка существует — она удаляется. Таким образом происходит отчистка репозитория от временных или завершивших свой жизненный цикл веток. Это помогает уменьшить засорение репозитория и снижает риск конфликты в дальнейшем.

Block POST

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

Примеры сценариев использования

Use Case 1: Полный перенос схемы между окружениями

1. Пользователь инициирует перенос схемы (через Jenkins или вручную создаёт PR).

2. Jenkins создает новую ветку и PR в Bitbucket, пишет статус OPEN в файл.

3. Bitbucket рассылает webhook о создании PR.

4. Jenkins валидирует параметры, схему, совместимость.

5. Jenkins уведомляет пользователя о создании PR (email).

6. Ревьювер проверяет и мёржит (или отклоняет) PR.

7. Webhook ловит событие merge/decline, обновляет статус файла.

8. Jenkins реагирует: a. Если MERGED, публикует схему на целевом Schema Registry, настраивает совместимость, удаляет ветку и файл статуса, уведомляет пользователя. b. Если DECLINED, удаляет ветку и файл статуса, уведомляет пользователя. c. Если за 7 дней нет изменений — пайплайн завершает работу, уведомляет пользователя.

Use Case 2: Только тесты (TESTS ONLY)

1. Пользователь запускает пайплайн с параметром TESTS_ONLY.
2. Jenkins выполняет юнит-тесты (валидация параметров, генерация имени ветки и т.д.).
3. Jenkins завершает работу.