{"meta":{"title":"Поддержание стандартов кодовой базы в развертывании GitHub Copilot","intro":"Сохраняйте контроль над кодом вашего предприятия с помощью правил, функций безопасности и эффективного обучения.","product":"GitHub Copilot","breadcrumbs":[{"href":"/ru/copilot","title":"GitHub Copilot"},{"href":"/ru/copilot/tutorials","title":"Учебники"},{"href":"/ru/copilot/tutorials/roll-out-at-scale","title":"Развертывание в масштабе"},{"href":"/ru/copilot/tutorials/roll-out-at-scale/govern-at-scale","title":"Управляйте в масштабах"},{"href":"/ru/copilot/tutorials/roll-out-at-scale/govern-at-scale/maintain-codebase-standards","title":"Поддержание стандартов кодовой базы"}],"documentType":"article"},"body":"# Поддержание стандартов кодовой базы в развертывании GitHub Copilot\n\nСохраняйте контроль над кодом вашего предприятия с помощью правил, функций безопасности и эффективного обучения.\n\nБольшинство предприятий осознают преимущества для продуктивности, которые могут принести инструменты программирования на базе ИИ. Однако многие опасаются, что неправильное использование в их компании, например вредоносные подсказки или принятие предложений ИИ разработчиками без рассмотрения, приведёт к нарушению стандартов их кодовой базы.\n\nВы можете снизить эти риски, создав свою GitHub среду и рабочую культуру для эффективного управления. Главное преимущество GitHub Copilot заключается в том, что он встроен в платформу GitHub , которая уже содержит ряд функций для корпоративного управления кодом.\n\n## 1. Требовать pull requests и отзывы\n\nРазработчики и злоумышленники никогда не должны иметь возможность в одиночестве применять непроверенные предложения или работу агентов напрямую к чувствительным кодовым базам. Перед тем, как пользователи смогут интегрировать код в производственные базы и другие важные ветки, вам должен **понадобиться одобренный pull** request.\n\nДля этого создайте набор правил:\n\n1. Определите организации или репозитории, содержащие нужные вам кодовые базы, и **примените к ним собственное свойство** . Это позволит вам легко нацеливать эти ресурсы в наборе правил. См\\[. раздел AUTOTITLE или [Управление настраиваемыми свойствами для репозиториев в организации](/ru/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization)]\\(/enterprise-cloud\\@latest/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/managing-custom-properties-for-organizations).\n\n   В качестве альтернативы вы можете вручную добавить эти защищённые ресурсы в набор правил или таргетировать их на основе определённой конвенции именования.\n\n2. Создайте набор правил для филиала для вашего предприятия. См [. раздел AUTOTITLE](/ru/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-code-governance#creating-a-branch-or-tag-ruleset).\n\n   * Включите хотя бы **правила Требовать pull request перед слиянием** и **Block force pushes** . В соответствии с правилом «Требуется pull request» убедитесь, что требуется хотя бы одно одобрение.\n   * При необходимости включите другие правила. Например, если вас беспокоит, что злоумышленники могут захватить pull request, обязательно **игнорируйте устаревшие одобрения pull** request, когда появляются новые коммиты.\n\n3. Поощряйте администраторов репозиториев настраивать файлы CODEOWNERS для конкретных файлов в репозиториях. При изменении этих файлов он автоматически запросит проверку у владельцев кода.\n\n   Затем вы можете вернуться к набору правил и включить **правило «Требовать проверку от владельцев кода** ».\n\n4. Поощряйте владельцев организаций и администраторов репозиториев создавать более конкретные правила, так как они, скорее всего, лучше осведомлены о требованиях к своему коду.\n\n   Эти наборы правил дополнят базовый уровень, который вы определили на уровне предприятия, но никогда не отменяют его.\n\n## 2. Проверьте свой код\n\nХорошие практики DevOps гарантируют, что ваш код автоматически тестируется перед слиянием и развертыванием, минимизируя риск ошибок, входящих в стандартные ветки и появления в производственных средах.\n\n1. Включите GitHub Actions или включите другую систему CI/CD.\n2. Поощряйте разработчиков писать тесты для всех функций и интегрировать тесты в GitHub Actions рабочие процессы.\n3. Поощряйте владельцев организаций или репозиториев создавать наборы правил и добавлять важные рабочие процессы в **правило «Требуйте прохождения рабочих процессов перед объединением** ».\n\n## 3. Сканировать код на наличие уязвимостей\n\nCopilot уже разработан так, чтобы избежать внедрения уязвимостей в вашу кодовую базу. Например, код, созданный API Copilot cloud agent , автоматически сканируется на наличие уязвимых шаблонов и секретов, таких как API-ключи.\n\nОднако рекомендуется регулярно сканировать весь код на наличие уязвимостей и секретов, чтобы не допустить их внедрения разработчиками.\n\n1. В качестве отправной точки примените и внедрите базовую **конфигурацию безопасности** в ваших организациях. Это набор настроек поддержки для функций безопасности. Мы рекомендуем включать code scanning, secret scanningи защиту от секретов push. См [. раздел AUTOTITLE](/ru/code-security/how-tos/secure-at-scale/configure-organization-security/establish-complete-coverage/create-custom-configuration#creating-a-secret-protection-and-code-security-configuration).\n2. По мере того как вы узнаете о своих потребностях, создавайте дополнительные индивидуальные конфигурации или применяйте детализированные настройки на уровне репозитория.\n3. Чтобы контролировать code scanning пулл-запросы, вернитесь к набору правил и включите **правило «Требовать code scanning результаты** ».\n\n## 4. Создайте рекомендации для Copilot\n\nЧтобы повысить качество Copilotпредложений в первую очередь, следует создавать индивидуальные инструкции. Эти инструкции добавляют контекст ко всем подсказкам, которые советуют Copilot следовать стандартам кодирования вашей компании.\n\n1. Чтобы создать хорошую базу, создайте **индивидуальные инструкции на уровне организации**. Это могут быть стандарты высокого уровня, которые, скорее всего, применимы к любому репозиторию. Однако обратите внимание, что эти инструкции применяются только к GitHub сайту. См [. раздел AUTOTITLE](/ru/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-organization-instructions).\n2. Для более полного освещения поощущайте разработчиков и администраторов репозиториев **писать собственные инструкции для конкретных репозиториев**. Они применимы в большем количестве, чем инструкции по организации, и могут более подробно описывать каждый проект и его требования. См [. раздел AUTOTITLE](/ru/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions).\n\n## 5. Поощрять лучшие практики\n\nПри наличии жёстких ограничений разработчики уже должны иметь возможность эффективно использовать ИИ. Однако важно проводить обучение по инструментам ИИ и создавать культуру, в которой лучшие практики поощряются, а не просто применяются.\n\n1. Сообщите о своих настройках управления и ожиданиях вашей компании относительно того, как разработчики должны использовать Copilot. Например, если вся работа агента должна быть тщательно рассмотрена, убедитесь, что этот процесс установлен и доведён до сознания.\n2. Попросите разработчиков выполняться `/security-review` перед Copilot CLI открытием запроса на вытягивание или запросом проверки. Этот процесс рассматривается как упрощенная проверка, а затем продолжите процесс проверки стандартного запроса на вытягивание. Дополнительные сведения см. в разделе [Лучшие практики для GitHub Copilot CLI](/ru/copilot/how-tos/copilot-cli/cli-best-practices#code-review-assistance).\n3. Создавайте ресурсы для адаптации, такие как внутренняя документация или видео. Для начала делитесь существующими ресурсами, такими как [Лучшие практики использования GitHub Copilot](/ru/copilot/get-started/best-practices) и [AUTOTITLE.](/ru/copilot/tutorials/copilot-cookbook)\n4. Предлагайте постоянное обучение и поддержку, например, мастер-классы. В успешных запусках многие компании выявляют «чемпионов», которые могут обучить других эффективному использованию Copilot .\n\n## 6. Планируйте худшее\n\nДаже при самых строгих ограничениях всегда возможно, что уязвимый или подверженный ошибкам код будет объединён, независимо от того, используют ли ваши разработчики инструменты ИИ.\n\nЧтобы подготовиться к таким ситуациям, нужно спланировать, как вы будете решать проблемы, и донести этот план до застройщиков. Рассмотрим пример.\n\n1. Отменить ошибочный pull request и откатить развертывание.\n2. Создайте пост для обсуждения, анализируя, что пошло не так и как этого избежать в будущем.\n3. Проверьте журналы аудита на предмет обхода правил, неправильных разрешений или изменений в настройках управления.\n\n## 7. Проверьте качество кода\n\nЕсли вы уверены в своей модели управления, но всё же беспокоитесь, что со временем Copilot это снизит качество вашей кодовой базы, вы можете измерить это в ходе внедрения. Если включено, GitHub Code Quality он показывает показатели состояния кода ваших репозиториев. См [. раздел AUTOTITLE](/ru/code-security/concepts/code-quality/code-quality)."}