GitHub Code Quality с 20 июля 2026 года: что проверить до включения платных проверок

GitHub объявила, что Code Quality переходит из публичного preview в общий доступ 20 июля 2026 года. В описании указаны лицензия за активного коммиттера, отдельное потребление AI-возможностей и использование GitHub Actions для детерминированного анализа. Перед включением нужно посчитать не только пользу, но и расходы.

Preview удобно включить для эксперимента, не оценивая его как постоянную статью бюджета. После перехода в общий доступ настройка становится частью рабочего процесса и может влиять на оплату организации.

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

Разделите базовую оплату, AI-проверку pull request, Autofix и использование Actions. Даже если детерминированный анализ предсказуем, агентные функции могут иметь отдельное потребление.

Соберите фактическую картину по организации. Не оценивайте стоимость по числу сотрудников в штате: важны активные коммиттеры и репозитории, где функция включена.

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

Определите, какие workflow будут запускать анализ и сколько минут они потребляют. Включайте Code Quality сначала на одном проекте, чтобы увидеть реальную нагрузку.

До включения решите, что считается проблемой, а что — рекомендацией. Quality gate должен блокировать merge только по измеримому критерию, который команда готова исправлять.

Порог покрытия не должен быть самоцелью. Учитывайте критичные модули, тестируемость и тип проекта. Зафиксируйте, кто может изменить правило и как оформляется исключение.

Начните с предупреждений, а не с жёсткой блокировки всего репозитория. После нескольких циклов посмотрите, какие находки действительно связаны с дефектами, а какие создают шум.

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

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

Убедитесь, что включение на уровне организации не распространилось на все репозитории. Проверьте права владельцев и автоматические rulesets.

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

Команде важны общие правила и отчёты, а индивидуальному разработчику — быстрый локальный тест. Не включайте дорогой сервис только ради красивого score.

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