Skip to main content

Внедрение GitHub Actions на предприятии

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

Сведения о GitHub Actions для предприятий

GitHub Actions — это платформа непрерывной интеграции и непрерывной поставки (CI/CD), которая позволяет автоматизировать конвейер сборки, тестирования и развертывания. С помощью GitHub Actions ваша компания может автоматизировать, персонализировать и выполнять рабочие процессы разработки программного обеспечения, такие как тестирование и развертывание. Дополнительные сведения см. в разделе Сведения о GitHub Actions для предприятий.

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

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

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

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

Дополнительные сведения см. в разделе[ "AUTOTITLE", "Управление параметрами GitHub Actions для репозитория" и "Применение политик для GitHub Actions в вашем предприятии](/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#managing-github-actions-permissions-for-your-organization)".

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

Вы можете получить доступ к сведениям о действиях, связанных с GitHub Actions в журналах аудита для вашего предприятия. Если компании требуется хранить эту информацию дольше, чем хранятся данные журнала аудита, спланируйте экспорт и хранение этих данных за пределами GitHub. Дополнительные сведения см. в разделе "[AUTOTITLE" иПотоковая передача журнала аудита для предприятия](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/exporting-audit-log-activity-for-your-enterprise)".

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

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

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

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

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

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

Необходимо спланировать место хранения секретов. Рекомендуется хранить секреты в 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 требуются средства выполнения ntcnjd. Вы можете использовать средства выполнения тестов, размещенных в GitHub или средства выполнения тестов локального размещения. 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Репозиторий».

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