Сведения о GitHub Actions для предприятий
GitHub Actions — это платформа непрерывной интеграции и непрерывной поставки (CI/CD), которая позволяет автоматизировать конвейер сборки, тестирования и развертывания. С помощью GitHub Actions ваша компания может автоматизировать, персонализировать и выполнять рабочие процессы разработки программного обеспечения, такие как тестирование и развертывание. Дополнительные сведения см. в разделе Сведения о GitHub Actions для предприятий.
Перед внедрением GitHub Actions в крупной компании необходимо сначала спланировать внедрение и принять решение относительно того, как предприятие будет использовать GitHub Actions, чтобы обеспечить оптимальную поддержку ваших уникальных потребностей.
Система управления и соответствие требованиям
Необходимо разработать план по контролю за использованием GitHub Actions на предприятии и соответствия нормативным требованиям.
Определите, какие действия и повторно используемые рабочие процессы будут использоваться разработчиками. Сначала определите, разрешены ли сторонние действия и повторно используемые рабочие процессы, которые не были созданы 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).](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#managing-github-actions-permissions-for-your-repository)
Рассмотрите возможность объединения OpenID Connect (OIDC) с повторно используемыми рабочими процессами для обеспечения согласованного развертывания в репозитории, организации или организации. Это можно сделать, определив условия доверия для облачных ролей на основе многократно используемых рабочих процессов. Дополнительные сведения см. в разделе Использование OpenID Connect с многократно используемыми рабочими процессами.
Вы можете получить доступ к сведениям о действиях, связанных с GitHub Actions в журналах аудита для вашего предприятия. Если компании требуется хранить эту информацию дольше, чем хранятся данные журнала аудита, спланируйте экспорт и хранение этих данных за пределами GitHub. Дополнительные сведения см. в разделе [AUTOTITLE и Экспорт действий журнала аудита для предприятия](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise).
Принцип наименьшей привилегии можно применять путем администрирования пользовательских ролей организации для доступа к параметрам в конвейере CI/CD GitHub Actions. Дополнительные сведения о пользовательских ролях организации см. в разделе Сведения о пользовательских ролях организации.
Безопасность
Необходимо спланировать методики усиления защиты для GitHub Actions.
Усиление защиты отдельных рабочих процессов и репозиториев
Создайте план обеспечения безопасности для пользователей, использующих функции GitHub Actions в вашей организации. Дополнительные сведения об этих методиках см. в разделе Защита системы безопасности для GitHub Actions.
Вы также можете поощрять повторное использование рабочих процессов, которые уже оценивались с точки зрения безопасности. Дополнительные сведения см. в разделе Innersourcing.
Защита доступа к секретам и ресурсам развертывания
Необходимо спланировать место хранения секретов. Рекомендуется хранить секреты в GitHub, однако можно также хранить секреты в поставщике облачных служб.
В GitHubможно хранить секреты на уровне репозитория или организации. Секреты на уровне репозитория могут быть ограничены рабочими процессами в определенных средах, например в рабочей или тестовой среде. Дополнительные сведения см. в разделе Использование секретов в GitHub Actions.
Необходимо добавить защиту утверждения вручную для конфиденциальных сред, чтобы рабочие процессы должны быть утверждены перед получением доступа к секретам сред. Дополнительные сведения см. в разделе Управление средами для развертывания.
Соображения безопасности для действий сторонних разработчиков
С использованием действий из сторонних репозиториев в GitHub связаны существенные риски. Если вы разрешаете действия сторонних разработчиков, необходимо разработать внутренние инструкции, которые помогут вашей команде следовать рекомендациям, таким как закрепление действий при полной фиксации SHA. Дополнительные сведения см. в разделе Защита системы безопасности для GitHub Actions.
Частная сеть с размещенными на сайте GitHub средствами выполнения
Вы можете использовать GitHubразмещенных в виртуальной сети Azure. Это позволяет использовать GitHubуправляемой инфраструктурой для CI/CD, обеспечивая полный контроль над сетевыми политиками запуска. Дополнительные сведения о виртуальной сети Azure см. в статье "Что такое Azure виртуальная сеть?" в документации По Azure. Дополнительные сведения см. в разделе Сведения о частных сетях Azure для размещенных в GitHub runners в вашей организации.
Выбор внутреннего источника
Подумайте о том, как ваше предприятие может использовать функции GitHub Actions для выбора внутреннего источника автоматизации. Выбор внутреннего источника — это способ реализации преимуществ методологий с открытым исходным кодов во внутреннем цикле разработки программного обеспечения. Дополнительные сведения см. в разделе Общие сведения о выборе внутреннего источника в разделе «Ресурсы GitHub».
Чтобы совместно использовать действия в организации, не публикуя их в открытом доступе, можно сохранить действия во внутреннем репозитории, а затем разрешить этому репозиторию доступ к рабочим процессам GitHub Actions в других репозиториях, принадлежащих тому же или любому другому отделу в организации. Дополнительные сведения см. в разделе Совместное использование действий и рабочих процессов с вашим предприятием.
При повторном использовании рабочих процессов команда может вызывать один рабочий процесс из другого рабочего процесса, избегая точного дублирования. Повторно используемые рабочие процессы способствуют соблюдению рекомендаций, помогая команде использовать рабочие процессы, которые грамотно разработаны и уже успешно протестированы. Дополнительные сведения см. в разделе Повторное использование рабочих процессов.
Чтобы предоставить начальное место для разработчиков создания новых рабочих процессов, можно использовать шаблоны рабочих процессов. Это не только экономит время разработчиков, но и обеспечивает согласованность и внедрение рекомендованных практических методик в вашей организации. Дополнительные сведения см. в разделе Создание шаблонов рабочих процессов для организации.
Управление ресурсами
Вы должны спланировать управление ресурсами, необходимыми для использования GitHub Actions.
Средства выполнения
Для рабочих процессов GitHub Actions требуются средства выполнения. Вы можете использовать GitHubразмещенных в среде runners или локальных runners. GitHub управляет обслуживанием и обновлением для GitHubразмещенных средств выполнения. Дополнительные сведения см. в разделе Использование средств выполнения, размещенных в GitHub.
Чтобы управлять собственными ресурсами, конфигурацией или географическим расположением виртуальных машин runner, используйте локальные средства выполнения. Дополнительные сведения см. в разделе О самостоятельно размещенных средствах выполнения.
Если вы хотите больше контроля над сетевыми политиками для пользователей, используйте локальные средства выполнения или частные сетевые параметры для GitHubразмещенных runners. Дополнительные сведения о параметрах частной сети см. в разделе Сведения о частной сети с размещенными на сайте GitHub средствами выполнения.
Если вы используете автономные модули выполнения, необходимо решить, следует ли использовать физические машины, виртуальные машины или контейнеры. Физические компьютеры будут хранить остатки предыдущих заданий, поэтому виртуальные машины будут использоваться только при использовании нового образа для каждого задания или очистки компьютеров после выполнения каждого задания. При выборе контейнеров следует знать, что автоматическое обновление средства выполнения завершает работу контейнера, что может привести к сбою рабочих процессов. Эту проблему нужно решить, запретив автоматическое обновление или пропуская команду, чтобы удалить контейнер.
Также необходимо решить, куда будет добавлено каждое из средств выполнения тестов. Можно добавить средство выполнения тестов локального размещения в отдельный репозиторий или сделать средство доступным для всей организации или всего предприятия. Добавление средств выполнения тестов на уровне организации или предприятия позволяет совместно использовать такие средства. Из-за этого может уменьшиться размер инфраструктуры средства выполнения тестов. Политики можно использовать для ограничения доступа к средствам выполнения тестов локального размещения на уровнях организации и предприятия, назначив группы средств выполнения тестов определенным репозиториям или организациям. Дополнительные сведения см. в разделе [AUTOTITLE и Добавление локальных средств выполнения](/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups). Вы также можете использовать политики, чтобы запретить пользователям использовать локальные модули выполнения на уровне репозитория. Дополнительные сведения см. в разделе Применение политик для GitHub Actions в вашем предприятии.
Рекомендуется использовать автоматическое масштабирование для автоматического увеличения или уменьшения числа доступных локальных модулей выполнения. Дополнительные сведения см. в разделе Автомасштабирование с помощью локальных средств выполнения.
Наконец, можно попробовать усилить безопасность для средств выполнения тестов локального размещения. Дополнительные сведения см. в разделе Защита системы безопасности для GitHub Actions.
Хранилище
Артефакты позволяют обмениваться данными между заданиями в рабочем процессе и хранить данные после завершения рабочего процесса. Дополнительные сведения см. в разделе Хранение и предоставление общего доступа к данным из рабочего процесса.
GitHub Actions также имеет систему кэширования, которую можно использовать для кэширования зависимостей для ускорения выполнения рабочего процесса. Дополнительные сведения см. в разделе Кэширование зависимостей для ускорения рабочих процессов.
Параметры политики можно использовать для GitHub Actions для настройки хранилища артефактов рабочих процессов, кэшей и хранения журналов. Дополнительные сведения см. в разделе Применение политик для GitHub Actions в вашем предприятии.
Некоторые хранилища включены в подписку, но дополнительное хранилище повлияет на ваш счет. Необходимо учитывать эти затраты при планировании. Дополнительные сведения см. в разделе Сведения о выставлении счетов за GitHub Actions.
Отслеживание использования
Можно запланировать отслеживание использования GitHub Actions вашим предприятием, например, регулярность запуска рабочих процессов, количество успешных запусков и сбоев, а также использованием тех или иных рабочих процессов конкретными репозиториями.
Вы можете просмотреть основные сведения об использовании хранилища и передачи данных GitHub Actions для каждой организации в вашей организации с помощью параметров выставления счетов. Дополнительные сведения см. в разделе Просмотр сведений об использовании GitHub Actions.
Для получения более подробных данных об использовании можно использовать веб-перехватчики для подписки на сведения о заданиях рабочего процесса и запусках рабочих процессов. Дополнительные сведения см. в разделе Сведения о веб-перехватчиках.
Спланируйте, как предприятие будет передавать данные из этих веб-перехватчиков в систему архивации данных. Можно использовать CEDAR.GitHub.Collector — средство с открытым исходным кодом, которое собирает и обрабатывает данные веб-перехватчика из GitHub. Дополнительные сведения см. в статье «Microsoft/CEDAR.GitHub.CollectorРепозиторий».
Кроме того, следует спланировать, как ваши команды будут получать необходимые данные из системы архивации.
Следующие шаги
Затем узнайте, как спланировать миграцию на GitHub Actions для вашего предприятия от другого поставщика. См . раздел AUTOTITLE.