Налаштування інтеграції Бітрікс24 з GitHub
Менеджер питає статус задачі — розробник відповідає «на рев'ю». Pull request в GitHub уже змерджили, а задача в Б24 досі «В роботі». Ручний міст між кодом і трекером ламається щодня. Ми прибираємо цей міст, зв'язуючи коміти, PR та деплої з задачами Б24 напряму. Наші інженери налаштовують інтеграцію під ключ, щоб ви забули про розсинхронізацію.
Проблеми, які вирішуємо
У типовому проєкті розробник витрачає до 30% часу на ручне оновлення статусів задач. Автоматизація через вебхуки та API скорочує цей час у 10 разів і виключає людські помилки. Крім того, менеджери та QA отримують прозору картину: кожен коміт прив'язаний до задачі, кожен PR змінює статус, кожен деплой логується. Це не просто зручність — це прозорість розробки для бізнесу.
Як ми це робимо: архітектура інтеграції
Зв'язка використовує 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:
| Подія GitHub | Канал Б24 | Формат повідомлення |
|---|---|---|
push |
Чат проєкту | Автор, гілка, список комітів з посиланнями |
pull_request.opened |
Чат проєкту | Назва PR, автор, гілка, посилання |
pull_request.merged |
Чат проєкту + сповіщення відповідальному | PR змерджено, хто змерджив |
pull_request_review |
DM автору PR | Результат рев'ю: approved/changes_requested |
issues.opened |
Чат проєкту | Новий issue, автор, текст |
release.published |
Загальний чат / канал releases | Версія, changelog, посилання |
Повідомлення надсилаються через 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 — основний тригер для оновлення статусів задач:
- PR відкрито → задача переходить у статус «На рев'ю» (
tasks.task.updateз новимSTATUS). - PR отримав approve → задача переходить у «Рев'ю пройдено» (кастомний статус).
- PR змерджено → задача переходить у «На тестуванні» або «Виконано» (налаштовується).
- PR закрито без мерджа → задача повертається у «В роботі».
Middleware визначає задачу за branch name (наприклад, feature/B24-1542-user-auth) або за текстом PR description.
Трекінг деплоїв
GitHub Actions або інші CI/CD-системи надсилають події deployment_status. Middleware транслює їх у Б24:
- Деплой на staging → коментар у задачі: «Розгорнуто на staging, посилання: {url}».
- Деплой на production → сповіщення у загальний чат + оновлення кастомного поля задачі
UF_DEPLOY_DATE. - Деплой failed → сповіщення відповідальному з логом помилки.
Це дозволяє менеджерам та 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 з обмеженими permissions).
- Б24: OAuth 2.0 з scope
task,im,user.
Middleware перевіряє заголовок X-Hub-Signature-256 для кожного вхідного webhook. Невалідні запити відхиляються.
Що входить у налаштування інтеграції?
| Етап | Тривалість | Результат |
|---|---|---|
| Аудит поточних процесів | 1-2 дні | Схема потоків даних, список тригерів |
| Розробка middleware | 3-5 днів | Робочий сервіс з логуванням |
| Налаштування вебхуків і токенів | 0.5 дня | Підключення репозиторіїв та Б24 |
| Тестування та налагодження | 1-2 дні | Перевірка всіх сценаріїв |
| Документація та навчання | 0.5 дня | Інструкція для команди |
Ми надаємо документацію з архітектури, доступи до middleware та навчання команди роботі з інтеграцією. Гарантуємо підтримку протягом місяця після запуску.
Чому обирають нас?
Більше 5 років ми налаштовуємо інтеграції Бітрікс24 з GitHub для клієнтів з різних галузей. Наші інженери — сертифіковані спеціалісти 1С-Бітрікс та GitHub Actions. Досвід — понад 50 успішних проєктів. Ми оцінюємо ваш проєкт безкоштовно та пропонуємо оптимальне рішення.
Зв'яжіться з нами, щоб обговорити деталі інтеграції та отримати консультацію.