Skip to main content

Enterprise Server 3.15 est actuellement disponible en tant que version finale (RC).

Introduction de GitHub Actions votre entreprise

Vous pouvez planifier le déploiement de GitHub Actions dans votre entreprise.

À propos de GitHub Actions pour les entreprises

GitHub Actions est une plateforme d’intégration continue et livraison continue (CI/CD) qui vous permet d’automatiser votre pipeline de génération, de test et de déploiement. Avec GitHub Actions, votre entreprise peut automatiser, personnaliser et exécuter vos workflows de développement logiciel comme les tests et les déploiements. Pour plus d’informations, consultez « À propos de GitHub Actions pour les entreprises ».

Avant d’introduire GitHub Actions dans une grande entreprise, il est nécessaire de d’abord établir un plan d’adoption et de prendre des décisions sur la manière dont l’entreprise va utiliser GitHub Actions pour répondre aux mieux à ses besoins uniques.

Gouvernance et conformité

Vous devez établir un plan pour régir l’utilisation de GitHub Actions dans votre entreprise et satisfaire vos obligations de conformité.

Identifiez les actions que vos développeurs seront autorisés à utiliser. Tout d’abord, décidez de permettre ou non l’accès aux actions de l’extérieur de votre instance. Dans votre entreprise, si les utilisateurs ont besoin d’accéder à d’autres actions de GitHub.com ou GitHub Marketplace, il existe quelques options de configuration. Pour plus d’informations, consultez « À propos de l’utilisation d’actions dans votre entreprise ».

Ensuite, décidez ou non d’autoriser des actions tierces qui n’ont pas été créé(e)s par GitHub. Vous pouvez configurer les actions qui sont autorisé(e)s à s’exécuter aux niveaux du dépôt, de l’organisation et de l’entreprise et choisir d’autoriser uniquement les actions qui sont créées par GitHub. Si vous autorisez des actions tierces, vous pouvez limiter les actions autorisées à celles qui ont été créées par des créateurs vérifiés ou à une liste d’actions spécifiques.

Pour plus d’informations, consultez « Gestion des paramètres de GitHub Actions pour un dépôt », « Désactivation ou limitation de la fonctionnalité GitHub Actions pour votre organisation » et « Application de stratégies pour GitHub Actions dans votre entreprise ».

Envisagez de combiner OpenID Connect (OIDC) avec des workflows réutilisables pour appliquer des déploiements cohérents dans votre dépôt, organisation ou entreprise. Pour cela, vous pouvez définir des conditions d’approbation au niveau de rôles cloud en fonction de workflows réutilisables. Pour plus d’informations, consultez « Utilisation d’OpenID Connect avec des workflows réutilisables ».

Vous pouvez accéder à des informations sur l’activité relative à GitHub Actions dans les journaux d’audit de votre entreprise. Si vos besoins métier nécessitent de conserver ces informations plus longtemps que les données des journaux d’audit, réfléchissez à la façon dont vous allez exporter et stocker ces données en dehors de GitHub. Pour plus d’informations, consultez « Streaming de journaux d’audit pour votre entreprise » et « Transfert de journaux ».

Vous pouvez pratiquer le principe du privilège minimum en administrant des rôles d’organisation personnalisés pour accéder aux paramètres dans votre pipeline CI/CD GitHub Actions. Pour plus d’informations sur les rôles d’organisation personnalisés, consultez « À propos des rôles d'organisation personnalisés ».

Sécurité

Vous devez réfléchir à votre approche pour renforcer la sécurité de GitHub Actions.

Renforcement de la sécurité des différents workflows et dépôts

Établissez un plan pour renforcer les bonnes pratiques de sécurité pour les personnes qui utilisent les fonctionnalités de GitHub Actions au sein de votre entreprise. Pour plus d’informations sur ces pratiques, consultez « Durcissement de la sécurité pour GitHub Actions ».

Vous pouvez aussi encourager la réutilisation des workflows qui ont déjà été évalués sur la plan de la sécurité. Pour plus d’informations, consultez « Inner sourcing ».

Sécurisation de l’accès aux secrets et aux ressources de déploiement

Vous devez prévoir où vous allez stocker vos secrets. Nous vous recommandons de stocker les secrets dans GitHub, mais vous pouvez choisir de les stocker chez un fournisseur de cloud.

Dans GitHub, vous pouvez stocker les secrets au niveau du dépôt ou de l’organisation. Les secrets au niveau du dépôt peuvent être limités aux workflows de certains environnements, par exemple de production ou de test. Pour plus d’informations, consultez « Utilisation de secrets dans GitHub Actions ».

Vous devez envisager d’ajouter une protection par approbation manuelle pour les environnements sensibles, de sorte que les workflows soient obligatoirement approuvés avant d’accéder aux secrets des environnements. Pour plus d’informations, consultez « Gestion des environnements pour le déploiement ».

Considérations de sécurité pour les actions tierces

Se procurer des actions sur des dépôts tiers de GitHub comporte un risque significatif. Si vous autorisez des actions tierces, vous avez tout intérêt à créer des directives internes qui encouragent votre équipe à suivre les bonnes pratiques, notamment en faisant correspondre les actions à un SHA de commit complet. Pour plus d’informations, consultez « Durcissement de la sécurité pour GitHub Actions ».

Inner sourcing

Réfléchissez à la façon dont votre entreprise peut utiliser les fonctionnalités de GitHub Actions pour l’inner sourcing de l’automatisation. L’inner sourcing est un moyen d’incorporer les avantages des méthodologies open source dans votre cycle de développement logiciel interne. Pour plus d’informations, consultez An introduction to innersource dans GitHub Resources.

Pour partager des actions au sein de votre entreprise sans les publier publiquement, vous pouvez les stocker dans un référentiel interne, puis configurer celui-ci pour autoriser l’accès aux workflows GitHub Actions dans d’autres référentiels appartenant à la même organisation ou à toute autre organisation de l’entreprise. Pour plus d’informations, consultez « Partage d’actions et de workflows au sein de votre entreprise ».

Avec les workflows réutilisables, votre équipe peut appeler un workflow à partir d’un autre workflow, ce qui évite une duplication exactement identique. Les workflows réutilisables favorisent les bonnes pratiques en aidant votre équipe à utiliser des workflows bien conçus et déjà testés. Pour plus d’informations, consultez « Réutilisation des workflows ».

Pour offrir aux développeurs un point de départ pour la génération de nouveaux workflows, vous pouvez utiliser des modèles de workflow. Non seulement ils font gagner du temps aux développeurs, mais ils favorisent également la cohérence et les bonnes pratiques à l’échelle de votre entreprise. Pour plus d’informations, consultez « Création de modèles de workflow pour votre organisation ».

Chaque fois que vos développeurs de workflows souhaitent utiliser une action stockée dans un dépôt privé, ils doivent d’abord configurer le workflow pour cloner le dépôt. Pour réduire le nombre de dépôts à cloner, envisagez de regrouper les actions couramment utilisées dans un même dépôt. Pour plus d’informations, consultez « À propos des actions personnalisées ».

Gestion des ressources

Vous devez réfléchir à la façon dont vous allez gérer les ressources nécessaires à l’utilisation de GitHub Actions.

Configuration matérielle requise

Vous devrez peut-être mettre à niveau les ressources processeur et mémoire pour votre instance GitHub Enterprise Server de façon à gérer la charge de GitHub Actions sans occasionner de perte de performances. Pour plus d’informations, consultez « Bien démarrer avec GitHub Actions pour GitHub Enterprise Server ».

Exécuteurs

Les workflows GitHub Actions nécessitent des exécuteurs. Vous serez appelé à héberger vos propres exécuteurs en installant l’application d’exécuteur auto-hébergé GitHub Actions sur vos propres ordinateurs. Pour plus d’informations, consultez « À propos des exécuteurs auto-hébergés ».

Déterminez si vous voulez utiliser des machines physiques, des machines virtuelles ou des conteneurs pour vos exécuteurs auto-hébergés. Les machines physiques conservent les restes des travaux précédents, tout comme les machines virtuelles, à moins que vous utilisiez une nouvelle image pour chaque travail ou que vous nettoyiez les machines après chaque exécution de travail. Si vous optez pour les conteneurs, sachez que la mise à jour automatique des exécuteurs arrête les conteneurs, ce qui peut entraîner l’échec des workflows. Vous devez trouver une solution à ce problème en empêchant les mises à jour automatiques ou en ignorant la commande afin de tuer le conteneur.

Vous devez aussi choisir à quel emplacement ajouter chaque exécuteur. Vous pouvez ajouter un exécuteur auto-hébergé à un dépôt individuel ou mettre l’exécuteur à la disposition d’une organisation entière ou de l’ensemble de votre entreprise. En ajoutant les exécuteurs au niveau de l’organisation ou de l’entreprise, vous pouvez en assurer le partage et ainsi contribuer à réduire la taille de votre infrastructure d’exécuteurs. Vous pouvez utiliser des stratégies pour limiter l’accès aux exécuteurs auto-hébergés aux niveaux de l’organisation et de l’entreprise en affectant des groupes d’exécuteurs à des dépôts ou des organisations spécifiques. Pour plus d’informations, consultez « Ajout d’exécuteurs auto-hébergés » et « Gestion de l’accès aux exécuteurs auto-hébergés à l’aide de groupes ». Vous pouvez également utiliser des stratégies pour empêcher les utilisateurs de se servir d’exécuteurs auto-hébergés au niveau du dépôt. Pour plus d’informations, consultez « Application de stratégies pour GitHub Actions dans votre entreprise ».

Envisagez d’utiliser la mise à l’échelle automatique pour augmenter ou diminuer automatiquement le nombre d’exécuteurs auto-hébergés disponibles. Pour plus d’informations, consultez « Mise à l’échelle automatique avec des exécuteurs auto-hébergés ».

Enfin, envisagez de renforcer la sécurité pour les exécuteurs auto-hébergés. Pour plus d’informations, consultez « Durcissement de la sécurité pour GitHub Actions ».

Stockage

Artifacts vous permet de partager des données entre travaux dans un workflow, et de stocker des données une fois ce workflow terminé. Pour plus d’informations, consultez « Stockage et partage des données d’un workflow ».

GitHub Actions a également un système de mise en cache que vous pouvez utiliser pour mettre en cache les dépendances afin d’accélérer les exécutions de workflow. Pour plus d’informations, consultez « Mise en cache des dépendances pour accélérer les workflows ».

Vous devez configurer le stockage d’objets blob externes pour les artefacts de workflow, les caches et d’autres journaux de workflow. Déterminez quel fournisseur de stockage pris en charge votre entreprise utilisera. Pour plus d’informations, consultez « Bien démarrer avec GitHub Actions pour GitHub Enterprise Server ».

Vous pouvez utiliser les paramètres de stratégie pour GitHub Actions afin de personnaliser le stockage des artefacts de workflow, les caches et la conservation des journaux. Pour plus d’informations, consultez « Application de stratégies pour GitHub Actions dans votre entreprise ».

Suivi de l'utilisation

Vous devez envisager de planifier le suivi de l’utilisation de GitHub Actions pour connaître notamment à quelle fréquence les workflows sont exécutés, combien d’exécutions aboutissent et combien échouent et quels dépôts utilisent quels workflows.

Vous pouvez utiliser des webhooks pour vous abonner à des informations sur les travaux et les exécutions de workflows. Pour plus d’informations, consultez « À propos des webhooks ».

Réfléchissez à la façon dont votre entreprise peut transmettre les informations de ces webhooks dans un système d’archivage de données. Vous pouvez envisager d’utiliser « CEDAR.GitHub.Collector », outil open source qui collecte et traite les données de webhooks de GitHub. Pour plus d’informations, consultez le dépôt Microsoft/CEDAR.GitHub.Collector.

Vous devez aussi prévoir comment vous allez permettre à vos équipes d’obtenir les données dont elles ont besoin depuis votre système d’archivage.