GitHub Enterprise Server 3.22 стал общедоступен 8 сентября 2026 года. Это свежий релиз self-hosted платформы GitHub для компаний, которым важно держать код, процессы разработки и часть инфраструктуры внутри собственного контура.
В версии 3.22 GitHub добавил изменения в администрирование, безопасность, правила ревью, GitHub Actions, Dependabot и Copilot. Ниже — не полный список release notes, а те пункты, которые сильнее всего влияют на работу команд и подготовку к обновлению.
GitHub Enterprise Server 3.22: дата релиза и статус
GitHub официально объявил общую доступность GHES 3.22 8 сентября 2026 года. Основной анонс опубликован в GitHub Changelog, а детальный список изменений доступен в официальных release notes.
Для администраторов это важно не только из-за новых функций. Перед апгрейдом нужно отдельно проверить совместимость интеграций, Actions runners, security-политик и собственных скриптов автоматизации.
Copilot CLI для disconnected и air-gapped окружений
Одна из самых заметных новинок — возможность настроить Copilot CLI для GitHub Enterprise Server в организациях, работающих без подключения к GitHub Cloud. Администратор может один раз настроить провайдера модели в GHES, после чего пользователи работают с Copilot CLI через свои GHES-учётные данные.
GitHub прямо помечает эту возможность как technical preview. Это означает, что интерфейсы и поведение ещё могут меняться. Для production-процессов не стоит строить критическую автоматизацию вокруг preview-функции без отдельного тестового контура.
Enterprise Teams стали generally available
Enterprise Teams вышли из public preview в общую доступность. Владельцы enterprise теперь могут централизованно управлять командами и доступом сразу на уровне нескольких организаций и репозиториев.
Для больших инсталляций это снижает необходимость дублировать одну и ту же структуру доступа в каждой организации. Но перед миграцией прав стоит проверить существующие роли, внешние identity-провайдеры и автоматизацию provisioning, чтобы не создать пересечение старой и новой модели доступа.
Rulesets стали гибче
В GHES 3.22 repository и organization rulesets получили более точные сценарии обхода правил. В частности, в bypass list теперь можно добавлять отдельных пользователей, а не только роли, команды и приложения.
Отдельно появился required reviewers rule для repository rulesets. Можно требовать ревью от конкретных команд для заданных веток, файлов или каталогов и задавать минимальное число одобрений. GitHub указывает, что это работает рядом с CODEOWNERS, а не заменяет его.
Практический пример: изменения в SQL-файлах можно направлять на обязательное ревью команды данных, а изменения в default branch — на дополнительное ревью security-команды.
Изменения в CodeQL и code scanning
GHES 3.22 поставляется с CodeQL 2.25.6. В release notes GitHub перечисляет обновления анализа для Swift, Kotlin, C#, .NET, Python, Java, JavaScript/TypeScript и других языков.
Для pull request analysis GitHub также описывает incremental analysis для ряда языков. Смысл в том, что анализ может сосредоточиться на изменённом коде вместо полного повторного прохода по проекту. Это особенно интересно большим репозиториям, где security-проверки заметно влияют на время обратной связи в PR.
GitHub Actions и self-hosted runners
В 3.22 есть несколько изменений вокруг Actions. Actions Runner Controller получил поддержку нескольких labels для одного scale set. Это позволяет точнее направлять задания на self-hosted runners без создания лишних параллельных наборов только ради комбинаций признаков.
Также GitHub добавил возможность указывать timezone в расписании workflow с cron. На момент релиза эта возможность отмечена как public preview, поэтому её тоже нужно воспринимать как ещё развивающуюся функцию.
Dependabot получил новые сценарии
В release notes перечислены расширения Dependabot: поддержка дополнительных экосистем и сценариев приватных registry, включая организационные настройки OIDC. Для enterprise-сред особенно важно изменение доступа к внутренним и приватным репозиториям между организациями одного enterprise.
Перед включением подобных функций нужно проверить модель доверия и audit log, а не только удобство автоматического обновления зависимостей.
Phased upgrade и подготовка окна обслуживания
Для администраторов важен новый phased upgrade execution. GitHub позволяет вынести pre-upgrade stage за пределы maintenance window. В официальных release notes указано, что предварительный этап может сократить время апгрейда внутри окна обслуживания до 20 минут.
Это не гарантия конкретного времени для любой инсталляции: фактический результат зависит от конфигурации и состояния instance. Но сама возможность разделить подготовительную и downtime-часть апгрейда полезна для систем с жёсткими требованиями к окну обслуживания.
Что проверить перед обновлением на GHES 3.22
- актуальную версию GHES и допустимый путь обновления;
- резервное копирование и процедуру восстановления;
- совместимость GitHub Apps, webhooks и внутренних интеграций;
- self-hosted runners и Actions Runner Controller;
- rulesets, CODEOWNERS и обязательные ревью;
- SSO, provisioning и enterprise access model;
- security workflows, CodeQL и Dependabot;
- известные проблемы конкретного релиза в официальных release notes.
Почему нельзя обновляться только ради одной функции
В enterprise-инфраструктуре полезная новая функция — недостаточная причина для немедленного production-апгрейда. Важнее оценить весь контур: плагины и интеграции, CI/CD, runner-ы, security-политики, резервное копирование и rollback.
Если GitHub Enterprise Server связан с внутренними сервисами через API, webhooks или собственные автоматизации, лучше заранее сделать инвентаризацию этих зависимостей. Такой подход относится не только к GHES: в A.S Groups используем тот же принцип при разработке и автоматизации веб-систем — сначала карта зависимостей, потом изменение production.
Итог
GitHub Enterprise Server 3.22 — содержательный релиз для команд, которым важны self-hosted разработка, централизованные права доступа и security-процессы. Самые заметные направления — Copilot CLI для изолированных сред, Enterprise Teams, более гибкие rulesets, обновления CodeQL, Actions и Dependabot.
Перед обновлением стоит пройти официальные release notes и проверить именно свою конфигурацию. Если нужна помощь с аудитом интеграций, CI/CD или автоматизацией вокруг GitHub и веб-инфраструктуры, можно описать задачу A.S Groups и приложить текущую схему.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.