Как сообщать команде об успешном или неудачном деплое

Команде нужен итог релиза

Разработчик видит зелёный pipeline, а коллеги не знают, обновилось ли приложение в production. При сбое важно быстро понять, какое окружение затронуто и где открыть детали.

Событие о релизе помогает сообщить итог всем участникам проекта. Сборка, тесты и развёртывание при этом остаются в вашей CI/CD-системе.

Какие этапы стоит отправлять

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

Пример шага отправки

На выбранной платформе подготовьте JSON и выполните запрос после нужного этапа. Ниже — учебные значения; замените их переменными вашей CI-системы.

$body = @{ event = "Релиз production завершён"; meta = @{ environment = "production"; version = "v2.4.0"; commit = "a1b2c3d"; result = "success" } } | ConvertTo-Json
Invoke-RestMethod -Uri "$env:ONTIK_BASE_URL/v1/events" -Method Post -Headers @{"X-Ontik-Key"=$env:ONTIK_API_KEY} -ContentType "application/json; charset=utf-8" -Body ([Text.Encoding]::UTF8.GetBytes($body))

curl --fail-with-body --max-time 10 \
  --request POST "$ONTIK_BASE_URL/v1/events" \
  --header "X-Ontik-Key: $ONTIK_API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{"event":"Релиз production завершён","meta":{"environment":"production","version":"v2.4.0","commit":"a1b2c3d","result":"success"}}'

curl --fail-with-body --max-time 10 \
  --request POST "$ONTIK_BASE_URL/v1/events" \
  --header "X-Ontik-Key: $ONTIK_API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{"event":"Релиз production завершён","meta":{"environment":"production","version":"v2.4.0","commit":"a1b2c3d","result":"success"}}'

ONTIK_BASE_URL должен содержать адрес backend без завершающего слеша, а ONTIK_API_KEY — ключ проекта из настроек окружения CI. Публичный адрес после запуска — https://app.ontik.ru.

Если подставляете название ветки или другой произвольный текст, формируйте JSON сериализатором, а не склеиванием строк shell. Кавычки в имени не должны ломать тело запроса.

Куда поставить этот шаг

1. Создайте проект по приложению или направлению, например «Production».
2. Добавьте участников и включите уведомления на нужных устройствах.
3. Поместите отправку success-события после deployment и health check.
4. Добавьте отдельную failure-ветку с другим заголовком.
5. Запустите учебный pipeline для success и failure и сравните полученные события.

GitHub Actions, GitLab CI, Jenkins и другие системы по-разному описывают условия запуска шага. Ontik требует одинаковый HTTP-контракт, но готовые конфигурации для всех CI-платформ в этот пример не входят.

Как не исказить результат pipeline

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

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