Configurer les Règles de Protection de Branche

Les règles de protection de branche sont vos gardiens automatisés. Elles garantissent que les code reviews ont lieu, que les tests passent et que les branches critiques restent stables. Une protection correctement configurée prévient les erreurs coûteuses et applique les standards de l'équipe sans surveillance manuelle.

Options de Protection

Configuration GitHub

Mise en Place de la Protection

PROTECTION DE BRANCHE GITHUB
═════════════════════════════

ACCÈS :
─────────────────────────────────────
Settings → Branches → Add rule
├── Branch name pattern : main
└── Configurer les protections

PROTECTIONS REQUISES :
─────────────────────────────────────
☑ Exiger une pull request avant de merger
├── Approbations requises : 1 (petite équipe) ou 2 (grande)
├── Rejeter les approbations obsolètes
│   └── Changements après approbation nécessitent re-revue
├── Exiger revue des Code Owners
│   └── Utiliser fichier CODEOWNERS
└── Exiger approbation du push le plus récent
    └── Empêche commits sournois après approbation

☑ Exiger que les status checks passent
├── Exiger que les branches soient à jour
├── Ajouter checks :
│   ├── ci/build
│   ├── ci/test
│   ├── ci/lint
│   └── security/scan
└── Tous doivent passer avant merge

☑ Exiger résolution des conversations
└── Tous les commentaires PR doivent être résolus

☑ Exiger commits signés (optionnel)
└── Pour repos haute sécurité

RESTRICTIONS DE PUSH :
─────────────────────────────────────
☑ Restreindre qui peut push sur les branches correspondantes
├── Sélectionner équipes/utilisateurs autorisés
├── Seulement pour urgences
└── Habituellement : personne (tout via PR)

☑ Ne pas autoriser le contournement des paramètres ci-dessus
└── Même les admins doivent suivre les règles

☑ Bloquer les force pushes
└── Protéger l'historique

☑ Bloquer les suppressions
└── Ne peut pas supprimer les branches protégées

Rulesets GitHub

RULESETS GITHUB (PLUS RÉCENT)
═════════════════════════════

AVANTAGES PAR RAPPORT AUX RÈGLES DE BRANCHE :
─────────────────────────────────────
├── S'applique au niveau organisation
├── Cible plusieurs branches/repos
├── Permissions de bypass plus granulaires
├── Règles de tags incluses
├── Meilleure piste d'audit
└── Recommandé pour entreprise

CRÉATION D'UN RULESET :
─────────────────────────────────────
Repository → Settings → Rules → Rulesets

Nouveau ruleset :
├── Nom : "Protection Production"
├── Application : Active
├── Branches cibles : main, release/*
└── Configurer les règles

OPTIONS RULESET :
─────────────────────────────────────
Règles de branche :
├── Restreindre les créations
├── Restreindre les mises à jour
├── Restreindre les suppressions
├── Exiger historique linéaire
├── Exiger que les déploiements réussissent
├── Exiger commits signés
├── Exiger une pull request
├── Exiger status checks
└── Bloquer force pushes

Liste de bypass :
├── Admins du repository
├── Équipes spécifiques (ex: Équipe Release)
├── Deploy keys
└── Accès d'urgence défini

Configuration GitLab

Branches Protégées

BRANCHES PROTÉGÉES GITLAB
═════════════════════════

ACCÈS :
─────────────────────────────────────
Settings → Repository → Protected branches

CONFIGURATION :
─────────────────────────────────────
Branche : main

Autorisé à merger :
├── Maintainers (commun)
├── Developers + Maintainers
├── Personne (via MR seulement)
└── Contrôle basé sur les rôles

Autorisé à push :
├── Personne (recommandé)
├── Force workflow CI/MR
└── Tous les changements via MR

Autorisé à force push :
├── Non (toujours)
└── Protège l'historique

Approbation code owner :
├── Requis des CODEOWNERS
└── Expertise du domaine appliquée

PARAMÈTRES MERGE REQUEST :
─────────────────────────────────────
Settings → Merge Requests

☑ Les pipelines doivent réussir
☑ Tous les threads doivent être résolus
☑ Pipelines ignorés considérés réussis : Non
☑ Méthode de merge : Merge commit / Squash / Rebase
└── Préférence de l'équipe

Status Checks

Configuration des Checks

CONFIGURATION STATUS CHECKS
═══════════════════════════

CHECKS REQUIS :
├── ci/build         - Compilation réussie
├── ci/test          - Tests passent
├── ci/lint          - Code formaté
├── ci/coverage      - Couverture suffisante
├── security/scan    - Pas de vulnérabilités
└── deploy/staging   - Déploiement staging OK

COMPORTEMENT :
├── Tous les checks doivent passer
├── Pas de merge si check échoue
├── Retry automatique si flaky
└── Timeout configurable

Gestion des Urgences

Processus de Bypass

PROCESSUS BYPASS D'URGENCE
══════════════════════════

QUAND BYPASSER :
├── Incident de production critique
├── Vulnérabilité de sécurité active
├── Deadline réglementaire
└── Décidé par un senior/lead

PROCESSUS :
1. Documenter la raison de l'urgence
2. Obtenir approbation d'une personne autorisée
3. Effectuer le changement minimal
4. Créer tâche de revue post-hoc
5. Revue complète dès que possible
6. Post-mortem si nécessaire

AUDIT :
├── Qui a fait le bypass
├── Quand et pourquoi
├── Quel changement a été fait
├── Revue effectuée (quand)
└── Améliorations identifiées

Meilleures Pratiques

Règles d'Or

1. Protégez main/master : Toujours, sans exception
2. Exigez des revues : Au moins 1 approbation
3. CI obligatoire : Pas de merge sans tests verts
4. Pas de force push : Historique préservé
5. Bypass documenté : Urgences tracées

Checklist de Configuration

• [ ] Protection activée sur main/master
• [ ] PR requise pour tous les changements
• [ ] Au moins 1 approbation requise
• [ ] Status checks CI configurés
• [ ] Force push bloqué
• [ ] Suppression bloquée
• [ ] Processus d'urgence documenté

Liens Connexes

• Meilleures Pratiques de Collaboration Git
• Automatiser la Gestion des Branches
• Meilleures Pratiques Pipeline CI/CD
• Réviser du Code Efficacement