GitHub добавил внешние пользовательские свойства для бизнес-контекста репозиториев

GitHub открыл в публичном предварительном просмотре внешние пользовательские свойства. Функция позволяет переносить в репозитории бизнес-контекст из внешней системы, которая остается источником актуальных данных. Речь идет о сведениях о владельце сервиса, уровне критичности, стадии жизненного цикла и статусе соответствия требованиям.

Такой подход рассчитан на команды, которые ведут техническую информацию в CMDB, внутреннем портале разработчиков или собственной корпоративной системе. GitHub получает эти данные для отображения и управления, а обновлением занимается исходная платформа.

Какие сведения можно синхронизировать

Обычные пользовательские свойства GitHub можно редактировать в самом сервисе или через API. Внешние свойства работают иначе: внешняя система сохраняет исключительное право на изменение связанных значений. Это снижает риск расхождения между каталогом сервисов и репозиториями.

Элемент	Как используется в GitHub
Владелец сервиса	Поиск ответственной команды и группировка репозиториев
Уровень сервиса	Сегментация проектов по критичности
Стадия жизненного цикла	Фильтрация активных, тестовых и архивных компонентов
Статус соответствия	Передача контекста для процессов управления и контроля

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

Интеграции и доступ через API

Первым партнером функции стала платформа Port.io. При этом GitHub не ограничивает интеграции готовыми партнерскими решениями. Корпоративные команды могут создать собственное подключение через API внешних пользовательских свойств.

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

Что проверить перед использованием

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

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