Поддержание стандартов кодовой базы в развертывании GitHub Copilot

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

Кто может использовать эту функцию?

Enterprise owners

В этой статье

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

Вы можете снизить эти риски, настроив свою GitHub среду и рабочую культуру для эффективного управления. Главное преимущество GitHub Copilot заключается в том, что он встроен в платформу GitHub, которая уже содержит ряд функций для корпоративного управления кодом.

1. Требовать pull requests и отзывы

Разработчики и злоумышленники никогда не должны иметь возможность в одиночестве применять непроверенные предложения или работу агентов напрямую к чувствительным кодовым базам. Перед тем, как пользователи смогут интегрировать код в производственные базы и другие важные ветки, вам должен понадобиться одобренный pull request.

Для этого создайте набор правил:

  1. Определите организации или репозитории, содержащие нужные вам кодовые базы, и примените к ним собственное свойство . Это позволит вам легко нацеливать эти ресурсы в наборе правил. См[. раздел AUTOTITLE или Управление настраиваемыми свойствами для репозиториев в организации](/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/managing-custom-properties-for-organizations).

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

  2. Создайте набор правил для филиала для вашего предприятия. См . раздел AUTOTITLE.

    • Включите хотя бы правила Требовать pull request перед слиянием и Block force pushes . В соответствии с правилом «Требуется pull request» убедитесь, что требуется хотя бы одно одобрение.
    • При необходимости включите другие правила. Например, если вас беспокоит, что злоумышленники могут захватить pull request, обязательно игнорируйте устаревшие одобрения pull request, когда появляются новые коммиты.

  3. Поощряйте администраторов репозиториев настраивать файлы CODEOWNERS для конкретных файлов в репозиториях. При изменении этих файлов он автоматически запросит проверку у владельцев кода.

    Затем вы можете вернуться к набору правил и включить правило «Требовать проверку от владельцев кода ».

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

    Эти наборы правил дополнят базовый уровень, который вы определили на уровне предприятия, но никогда не отменяют его.

2. Проверьте свой код

Хорошие практики DevOps гарантируют, что ваш код автоматически тестируется перед слиянием и развертыванием, минимизируя риск ошибок, входящих в стандартные ветки и появления в производственных средах.

  1. Включите GitHub Actions или другую систему CI/CD.
  2. Поощряйте разработчиков писать тесты для всех функций и интегрировать тесты в рабочие процессы GitHub Actions.
  3. Поощряйте владельцев организаций или репозиториев создавать наборы правил и добавлять важные рабочие процессы в правило «Требуйте прохождения рабочих процессов перед объединением ».

3. Сканировать код на наличие уязвимостей

Copilot уже разработан так, чтобы избежать внедрения уязвимостей в вашу кодовую базу. Например, код, созданный Агент кодирования Copilot, автоматически сканируется на уязвимые шаблоны и секреты, такие как API-ключи.

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

  1. В качестве отправной точки примените и обеспечьте соблюдение рекомендуемой конфигурации безопасности GitHub в ваших организациях. Это набор настроек активации для систем безопасности, включая code scanning, secret scanning и защиту от push-пуша секретов. См . раздел AUTOTITLE.
  2. Когда вы узнаете больше о своих потребностях, создавайте индивидуальные конфигурации или применяйте детализированные настройки на уровне репозитория.
  3. Чтобы применить code scanning на pull requests, вернитесь к набору правил и включите правило Require code scanning результатов .

4. Создайте рекомендации для Copilot

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

  1. Чтобы создать хорошую базу, создайте индивидуальные инструкции на уровне организации. Это могут быть стандарты высокого уровня, которые, скорее всего, применимы к любому репозиторию. Однако обратите внимание, что эти инструкции применимы только к сайту GitHub. См . раздел AUTOTITLE.
  2. Для более полного освещения поощущайте разработчиков и администраторов репозиториев писать собственные инструкции для конкретных репозиториев. Они применимы в большем количестве, чем инструкции по организации, и могут более подробно описывать каждый проект и его требования. См . раздел AUTOTITLE.

5. Поощрять лучшие практики

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

  1. Сообщите о своих настройках управления и ожиданиях вашей компании относительно того, как разработчики должны использовать Copilot. Например, если вся работа агента должна быть тщательно рассмотрена, убедитесь, что этот процесс установлен и доведён до сознания.
  2. Создавайте ресурсы для адаптации, такие как внутренняя документация или видео. Для начала делитесь существующими ресурсами, такими как Лучшие практики использования GitHub Copilot и AUTOTITLE.
  3. Предлагайте постоянное обучение и поддержку, например, мастер-классы. В успешных запусках многие компании выявляют «чемпионов», которые могут обучить других эффективному использованию Copilot.

6. Планируйте худшее

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

Чтобы подготовиться к таким ситуациям, нужно спланировать, как вы будете решать проблемы, и донести этот план до застройщиков. Рассмотрим пример.

  1. Отменить ошибочный pull request и откатить развертывание.
  2. Создайте пост для обсуждения, анализируя, что пошло не так и как этого избежать в будущем.
  3. Проверьте журналы аудита на предмет обхода правил, неправильных разрешений или изменений в настройках управления.

7. Проверьте качество кода

Если вы уверены в своей модели управления, но всё же беспокоитесь, что Copilot со временем снизит качество вашей кодовой базы, вы можете измерить это в ходе внедрения. Если включено, GitHub Code Quality предоставляет метрики состояния кода ваших репозиториев. См . раздел AUTOTITLE.

Дальнейшие действия

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