Настройка интеграции Битрикс24 с GitHub

Настройка интеграции Битрикс24 с GitHub

Менеджер просит статус задачи — разработчик отвечает «в ревью». Менеджер не понимает, что это значит, и лезет в Б24, где задача до сих пор «В работе». Pull request в GitHub уже смёрджен, а задача в Б24 закроется только когда разработчик вспомнит. Между кодом и трекером — ручной мост, который ломается каждый день. Интеграция убирает этот мост и связывает коммиты, 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 определяет задачу по 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. Невалидные запросы отклоняются.

Что внедряем

• Middleware для связки GitHub-репозиториев с задачами и чатами Б24
• Уведомления о коммитах, PR и релизах в чатах Б24
• Автоматическую привязку коммитов к задачам по ID в commit message
• Обновление статусов задач по жизненному циклу PR
• Трекинг деплоев с уведомлениями в Б24
• Двустороннюю синхронизацию задач Б24 и GitHub Issues