Lab Niveau 16 — GitHub Organizations & Collaboration
Objectifs
Section titled “Objectifs”- Modéliser une architecture d’organisation GitHub avec des équipes (Teams) structurées.
- Appliquer le principe du moindre privilège (Least Privilege) sur les rôles et permissions.
- Rédiger et simuler la configuration de règles de protection de branches (Branch Protection Rules).
- Écrire une charte de workflow de collaboration d’équipe.
Exercice Pratique
Section titled “Exercice Pratique”Dans cet exercice, vous allez agir en tant que Tech Lead / Administrateur de la communauté HashCode Community pour structurer l’organisation et protéger la branche principale des dépôts critiques.
Étape 1 : Modélisation des Équipes (Teams)
Section titled “Étape 1 : Modélisation des Équipes (Teams)”Sur papier ou dans un fichier de notes temporaire :
- Créez une structure pour une organisation fictive de 50 personnes comprenant les équipes suivantes :
Core Team,Engineering,DevOps,Security,DocumentationetContributors. - Listez les membres fictifs à affecter à chaque équipe.
- Écrivez la cascade de permissions pour chaque équipe sur les dépôts
workshops,platformetoperation-sentinelen respectant le principe du moindre privilège.
Étape 2 : Définition des Rôles de Dépôts
Section titled “Étape 2 : Définition des Rôles de Dépôts”Associez la permission adéquate (Read, Triage, Write, Maintain, Admin) pour les scénarios suivants :
- L’équipe
Documentationdoit pouvoir éditer et valider le contenu des guides techniques sur le dépôtworkshops. - L’équipe
DevOpsdoit pouvoir configurer les secrets de déploiement et administrer les pipelines sur le dépôtplatform. - Les contributeurs externes (
Contributors) doivent pouvoir cloner le code du dépôt publiclabset soumettre des rapports de bugs, sans modifier le code directement.
Étape 3 : Spécification des Branch Protection Rules
Section titled “Étape 3 : Spécification des Branch Protection Rules”Sur votre dépôt de travail, définissez la politique de sécurité pour la branche principale main :
- Interdisez les pushs directs sur
main. - Imposez l’ouverture d’une Pull Request (PR) pour toute intégration de code.
- Exigez l’approbation (Approval) d’au moins 1 relecteur qualifié de la Team correspondante.
- Exigez le passage au vert des statuts de builds automatiques (CI).
Étape 4 : Rédiger la charte de workflow
Section titled “Étape 4 : Rédiger la charte de workflow”Rédigez un document synthétique décrivant le flux de travail que l’équipe d’ingénierie doit suivre pour chaque tâche (de l’ouverture de l’Issue à la fusion de la PR).
Checklist de validation
Section titled “Checklist de validation”- La structure des équipes (Teams) de l’organisation respecte le principe du moindre privilège.
- Les niveaux de permissions associés aux différents dépôts sont correctement documentés et justifiés.
- La configuration des Branch Protection Rules pour la branche
mainest rédigée et interdit tout push direct. - La charte du workflow d’équipe détaille l’assignation des responsabilités (Issue, PR, Reviewer, Maintainer).
Compétences acquises
Section titled “Compétences acquises”- Administration d’une GitHub Organization et gestion des Teams
- Application du principe du moindre privilège
- Protection de branche stratégique et règles de livraison
- Structuration de workflows d’ingénierie logicielle d’équipe
Fiches de révision
Section titled “Fiches de révision”Quelle permission sur un dépôt permet de configurer les règles de protection de branche ?
Cliquer pour révéler la réponseLa permission Maintain (ou Admin).
Cliquer pour voir la questionQu'est-ce que l'héritage de permissions dans les Teams GitHub ?
Cliquer pour révéler la réponseC'est le fait que tout membre ajouté à une équipe reçoit automatiquement toutes les permissions de dépôt attribuées à cette équipe.
Cliquer pour voir la questionPourquoi exige-t-on que les branches de PR soient à jour avec main avant la fusion ?
Cliquer pour révéler la réponsePour s'assurer que les modifications ont été testées avec le code de production le plus récent et éviter les régressions silencieuses.
Cliquer pour voir la questionÉvaluation des connaissances
Section titled “Évaluation des connaissances”Quel rôle au sein de l'organisation permet de modifier la facturation ou de supprimer l'organisation elle-même ?
Quelle permission GitHub permet de gérer les labels, fermer et assigner des issues sans pouvoir modifier le code ?
Que se passe-t-il si un développeur tente de pousser du code directement sur main alors qu'une Branch Protection Rule l'interdit ?