Skip to main content

Знакомство с GitHub Actions для вашего предприятия

Вы можете спланировать внедрение GitHub Actions в своё предприятие.

О GitHub Actions предпринимательстве

          GitHub Actions — это платформа непрерывной интеграции и непрерывной поставки (CI/CD), которая позволяет автоматизировать конвейер сборки, тестирования и развертывания. С GitHub Actions, ваше предприятие может автоматизировать, настраивать и выполнять рабочие процессы разработки программного обеспечения, такие как тестирование и развертывание. Дополнительные сведения см. в разделе [AUTOTITLE](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/about-github-actions-for-enterprises).

Прежде чем представить GitHub Actions крупное предприятие, сначала нужно спланировать внедрение и принять решения о том, как ваше предприятие будет использовать GitHub Actions его для оптимального соответствия вашим уникальным потребностям.

Система управления и соответствие требованиям

Вам следует разработать план, который будет регулировать использование и GitHub Actions выполнение ваших обязательств по соблюдению требований.

Определите, какие действия ваши разработчики смогут использовать. Во-первых, решите, позволите ли вы получить доступ к действиям рабочим процессам извне вашего экземпляра. Если пользователям предприятия требуется доступ к другим действиям из GitHub.com или GitHub Marketplace, можно использовать несколько параметров конфигурации. Для получения дополнительной информации см. Сведения об использовании действий в организации.

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

Дополнительные сведения см. в разделе AUTOTITLE, [AUTOTITLE[ и Управление настройками GitHub Actions для репозитория](/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#managing-github-actions-permissions-for-your-organization).](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enforcing-a-policy-to-restrict-the-use-of-github-actions-in-your-enterprise)

Рассмотрите возможность объединения OpenID Connect (OIDC) с повторно используемыми рабочими процессами для обеспечения согласованного развертывания в репозитории, организации или организации. Это можно сделать, определив условия доверия для облачных ролей на основе многократно используемых рабочих процессов. Дополнительные сведения см. в разделе Использование OpenID Connect с многократно используемыми рабочими процессами.

Вы можете получить информацию о деятельности, связанной с этим GitHub Actions , в журналах аудита вашего предприятия. Если вашему бизнесу нужно хранить эту информацию дольше, чем данные журнала аудита, планируйте, как вы будете экспортировать и хранить эти данные вне GitHub. Для получения дополнительной информации смотрите АВТОЗАГОЛОВКИ И АВТОЗАГОЛОВКИ.

          Вы можете практиковать принцип наименьшей привилегии, администрируя кастомные организационные роли для доступа к настройкам в вашем GitHub Actions CI/CD конвейере. Для получения дополнительной информации о ролях в индивидуальных организациях см. [AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles).

Безопасность

Вам стоит спланировать свой подход к усилению безопасности для GitHub Actions.

Усиление защиты отдельных рабочих процессов и репозиториев

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

Вы также можете поощрять повторное использование рабочих процессов, которые уже оценивались с точки зрения безопасности. Дополнительные сведения см. в разделе Innersourcing.

Защита доступа к секретам и ресурсам развертывания

Необходимо спланировать место хранения секретов. Мы рекомендуем хранить секреты в GitHub, но вы можете выбрать хранение секретов в облачном провайдере.

В GitHub, вы можете хранить секреты на уровне репозитория или организации. Секреты на уровне репозитория могут быть ограничены рабочими процессами в определенных средах, например в рабочей или тестовой среде. Дополнительные сведения см. в разделе Использование секретов в GitHub Actions.

Необходимо добавить защиту утверждения вручную для конфиденциальных сред, чтобы рабочие процессы должны быть утверждены перед получением доступа к секретам сред. Дополнительные сведения см. в разделе Управление средами для развертывания.

Соображения безопасности для действий сторонних разработчиков

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

Выбор внутреннего источника

Подумайте, как ваше предприятие может использовать функции GitHub Actions автоматизации внутреннего источника. Внутренний источник — это способ интегрировать преимущества методологий open source в ваш внутренний цикл разработки программного обеспечения. Для получения дополнительной информации см. раздел «Введение в внутренний источник » в GitHub разделе Ресурсы.

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

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

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

Управление ресурсами

Вам стоит спланировать, как вы будете управлять ресурсами, необходимыми для использования GitHub Actions.

Требования к аппаратному обеспечению

Возможно, потребуется обновить процессор и ресурсы ваш экземпляр GitHub Enterprise Server памяти, чтобы справиться с нагрузкой GitHub Actions без потери производительности. Дополнительные сведения см. в разделе Начало работы с GitHub Actions for GitHub Enterprise Server.

Средства выполнения

          GitHub Actions Рабочие процессы требуют раннеров. Вам придётся разместить собственные Runners, установив GitHub Actions самостоятельное приложение Runner на свои компьютеры. Для получения дополнительной информации см. [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners).

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

Также необходимо решить, куда будет добавлено каждое из средств выполнения тестов. Можно добавить средство выполнения тестов локального размещения в отдельный репозиторий или сделать средство доступным для всей организации или всего предприятия. Добавление средств выполнения тестов на уровне организации или предприятия позволяет совместно использовать такие средства. Из-за этого может уменьшиться размер инфраструктуры средства выполнения тестов. Политики можно использовать для ограничения доступа к средствам выполнения тестов локального размещения на уровнях организации и предприятия, назначив группы средств выполнения тестов определенным репозиториям или организациям. Дополнительные сведения см. в разделе [AUTOTITLE и Добавление локальных средств выполнения](/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups). Вы также можете использовать политики, чтобы запретить пользователям использовать локальные модули выполнения на уровне репозитория. Дополнительные сведения см. в разделе Применение политик для GitHub Actions в вашем предприятии.

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

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

Хранилище

          Артефакты позволяют обмениваться данными между заданиями в рабочем процессе и хранить данные после завершения рабочего процесса. Для получения дополнительной информации см. [AUTOTITLE](/actions/using-workflows/storing-workflow-data-as-artifacts).

          GitHub Actions Также есть система кэширования, которую можно использовать для кэширования зависимостей, чтобы ускорить запуск рабочих процессов. Дополнительные сведения см. в разделе [AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows).

Необходимо настроить внешнее хранилище blob для артефактов рабочих процессов, кэшей и других логов рабочих процессов. Определите, какой поддерживаемый поставщик хранилища будет использовать ваше предприятие. Дополнительные сведения см. в разделе Начало работы с GitHub Actions for GitHub Enterprise Server.

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

Отслеживание использования

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

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

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