Collaboration dans le cadre des contraintes de GHES
Les environnements GitHub Enterprise Server sont intentionnellement contraints de prendre en charge la sécurité, la conformité et le contrôle opérationnel. La compréhension de ces contraintes aide les équipes à collaborer efficacement sans frustration.
Dans cette unité, vous allez apprendre
- Impact des contraintes d’infrastructure sur la collaboration
- Comment l’automatisation diffère de GitHub.com
- Pourquoi la coordination avec les équipes de plateforme importe
Réalités de l’infrastructure et de l’automatisation
Sur GHES, l’automatisation telle que GitHub Actions s’appuie sur des exécuteurs auto-hébergés gérés par l’organisation. Ces agents peuvent être limités en nombre, en capacité ou en accès réseau, ce qui peut affecter la fiabilité et les performances du déroulement des opérations. Les dépendances externes peuvent nécessiter des miroirs ou des proxys, et certaines fonctionnalités natives cloud ne sont pas disponibles.
Ces limitations signifient que la collaboration et l’automatisation doivent être conçues avec l’environnement à l’esprit plutôt que d’assumer les valeurs par défaut du cloud.
Certaines entreprises exécutent CI/CD en dehors de GHES (par exemple, avec des systèmes de build internes) et intègrent les résultats dans les pull requests comme vérifications d'état. La disponibilité et les intégrations des fonctionnalités peuvent également varier en fonction de la configuration de l’instance GHES et de ce qui est approuvé par l’équipe de plateforme.
Collaboration avec les équipes de la plateforme et DevOps
Dans les environnements auto-gérés, les équipes de plateforme et devOps sont responsables de l’infrastructure GHES sous-jacente. Les développeurs dépendent souvent de ces équipes pour activer les fonctionnalités, gérer les exécuteurs et résoudre les problèmes d’infrastructure.
Une collaboration efficace comprend la compréhension des contraintes de plateforme, la communication des exigences au début et le traitement des équipes de plateforme en tant que partenaires dans le processus de développement plutôt que des fournisseurs de services externes.
Étape par étape : Diagnostiquer un échec de vérification ou de flux de travail (haut niveau)
Lorsqu'une vérification requise échoue ou reste en attente, adoptez une approche méthodique avant d'escalader.
Ouvrez le pull request et identifiez le test échoué ou en attente.
Ouvrez les détails de la vérification pour afficher les logs, les messages d’erreur et les horodatages.
Déterminez le type d’échec probable :
- Échec de test/build (problème de code ou de configuration)
- Échec de dépendance/réseau (restrictions de proxy/miroir/sortantes)
- Problème de capacité de l’exécuteur (travaux mis en file d’attente ou exécuteurs hors connexion)
Réexécutez les vérifications si elles sont autorisées après avoir corrigé la cause.
Si l’échec apparaît lié à l’infrastructure, capturez :
- Nom de la vérification défaillante
- Lien vers l’exécution/les journaux
- Horodatage et message d’erreur
- Indique si le problème est cohérent entre les référentiels ou uniquement celui-ci
Fournissez ces informations à la plateforme ou à l’équipe DevOps pour accélérer la résolution.
Principaux points à prendre : les environnements GHES hiérarchisent la sécurité et le contrôle opérationnel, de sorte qu’ils planifient efficacement les contraintes d’infrastructure et collaborent étroitement avec les propriétaires de la plateforme pour assurer la prédictible de la livraison.
Avec ces contraintes à l’esprit, vous pouvez appliquer le référentiel, le branchement, la protection et les pratiques des pull requests dans ce module pour collaborer efficacement dans les environnements GHES gérés par l'entreprise.