Налаштування інтеграції Бітрікс24 з GitHub

Налаштування інтеграції Бітрікс24 з GitHub

Менеджер запитує статус завдання — розробник відповідає «на ревю». Менеджер не розуміє, що це означає, і піддається до Б24, де завдання все ще «В роботі». Pull request у GitHub вже змерджений, але завдання закриється лише коли розробник згадає. Між кодом та трекером — ручний міст, який ламається щодня. Інтеграція видаляє цей міст і з'єднує коміти, PR та деплої з завданнями Б24 безпосередньо.

Архітектура інтеграції

Інтеграція використовує GitHub Webhooks та Б24 REST API. GitHub надсилає POST-запити за событами репозиторію. Middleware отримує ці запити, витягує дані та транслює їх в Б24.

GitHub (push/PR/issue) → Webhook → Middleware → Б24 REST API → Завдання/Чат
Б24 (подія завдання) → Webhook → Middleware → GitHub API → Issues/Labels

GitHub Webhooks налаштовуються на рівні репозиторію (Settings → Webhooks) або організації. Content type — application/json. Кожний webhook підписується HMAC-SHA256 через secret — middleware перевіряє підпис.

Сповіщення про коміти та PR у чаті Б24

Middleware маршрутизує события GitHub до каналів Б24:

Повідомлення надсилаються через im.message.add з форматуванням BB-кодами. Посилання на PR та коміти кликабельні.

Прив'язка комітів до завдань

Розробник указує ID завдання Б24 у повідомленні коміту: fix: resolve layout issue [B24-1542]. Middleware розбирає commit message, витягує ID і виконує дії:

• Додає коментар до завдання через task.commentitem.add з текстом коміту, автором та посиланням на diff.
• Якщо комбіт містить ключові слова (close, fix, resolve), middleware може автоматично перекладати завдання у статус «Виконано».
• Усі коміти, прив'язані до завдання, видимі в історії коментарів — менеджер розуміє, що відбувається з кодом.

Синхронізація статусів через PR

Pull request — основний тригер для оновлення статусів завдань:

1. PR відкритий → завдання переходить у статус «На ревю» (tasks.task.update з новим STATUS).
2. PR отримав approve → завдання переходить у «Ревю пройдено» (користувацький статус).
3. PR змерджений → завдання переходить на «На тестуванні» або «Виконано» (налаштовується).
4. PR закритий без мёрджу → завдання повертається в «В роботі».

Middleware визначає завдання за назвою гілки (наприклад, feature/B24-1542-user-auth) або за текстом опису PR.

Трекинг деплоїв

GitHub Actions або інші CI/CD-системи надсилають события deployment_status. Middleware транслює їх в Б24:

• Деплой на staging → коментар у завданні: «Розгорнуто на staging, посилання: {url}».
• Деплой на production → сповіщення в загальний чат + оновлення користувацького поля завдання UF_DEPLOY_DATE.
• Деплой невдалий → сповіщення відповідальному з логом помилки.

Це дозволяє менеджерам та QA бачити, коли функція готова до тестування, без запитань в чаті.

Зворотний зв'язок: завдання Б24 → GitHub Issues

Коли завдання певного типу створюється в Б24, middleware автоматично створює issue в GitHub через POST /repos/{owner}/{repo}/issues. Відображення:

• Назва завдання → title issue
• Опис → body (HTML конвертується в Markdown)
• Пріоритет → label (priority:high, priority:medium)
• Проект Б24 → репозиторій (через таблицю відповідностей)

Зворотне оновлення: коли issue закривається в GitHub, middleware закриває завдання в Б24.

Безпека

• GitHub: webhook secret для перевірки підпису. API-запити — через Personal Access Token або GitHub App (Installation Token з обмеженими дозволами).
• Б24: OAuth 2.0 з областю task,im,user.
• Middleware перевіряє заголовок X-Hub-Signature-256 для кожного webhook. Невалідні запити відхиляються.

Що ми реалізуємо

• Middleware для з'єднання репозиторіїв GitHub з завданнями та чатами Б24
• Сповіщення про коміти, PR та релізи в чатах Б24
• Автоматичну прив'язку комітів до завдань за ID у commit message
• Оновлення статусів завдань протягом життєвого циклу PR
• Трекинг деплоїв із сповіщеннями в Б24
• Двосторонню синхронізацію завдань Б24 та GitHub Issues