Tech & DevOps HubEspace Tech & DevOps: Explorez le monde du Dev, du Cloud et des outils DevOps à travers nos articles et discussions Explore the world of development, the cloud and DevOps tools
Les rulesets ou Règles de protection des branches
SonarQube CloudNous abordons ici les différentes stratégies Git, les bonnes pratiques du point de vue DevOps, et la mise en place des rulesets GitHub, ainsi que les vérifications finales pour sécuriser et structurer le workflow.
Les différents type de stratégies Git
Les stratégies Git, ou workflows, structurent la gestion des branches pour optimiser le développement collaboratif
Elles définissent comment créer les fonctionnalités, les correctifs (hotfixes) et la manière de livrer le code.
Stratégies principales et caractéristiques
Github Flow (Simple/Web):
Une branche main stable, et des branches feature qui sont fusionnées dès que la fonctionnalité est terminée et testée
Parfait pour les applications web et les petites équipes. Facilite la revue de code via les Pull Requests avant fusion
Gitflow (Structuré/Releases):
Modèle plus complexe adapté grande équipe et aux releases planifiées.
Il utilise une branche master/main (production), develop (intégration), et des branches séparées pour les fonctionnalités (feature), les pré-productions (release) et les correctifs (hotfix)
Trunk-based Development (DevOps Moderne):
Les développeurs fusionnent fréquemment leurs modifications (plusieurs fois par jour) dans une branche unique (trunk ou main)
Cela minimise les conflits de fusion et s'aligne parfaitement avec la CI/CD
GitLab Flow :
Hybride entre le GitHub Flow (trop simple pour la prod) et le Git Flow (trop complexe), il utilise des branches d'environnement (pre-production, production) pour plus de contrôle dans les pipelines CI/CD
du Point de vue devOps:
GitFlow, Github Flow... En DevOps, une stratégie de branchement définit comment une équipe collabore sur le code pour assurer une livraison continue et stable.
Le choix dépend de la complexité du projet et de la fréquence de déploiement.
Une stratégie Git multi-branche DevOps efficace structure le développement via des branches spécialisées (feature, develop, main/release) pour garantir la stabilité de la production, permettre des livraisons continues (CI/CD) et automatiser les tests.
Bonnes pratiques
Branches éphémères: Supprimez les branches de fonctionnalités immédiatement après la fusion pour éviter l'accumulation de dette technique
Branche de Release: Créer des branches spécifiques pour les versions afin de stabiliser le code avant la mise en production
Automatisation: Utiliser des pipelines CI/CD (Azure, Jenkins, GitHub Actions) déclenchés automatiquement pour valider le code à chaque merge
Ma configuration correspond à un modèle "GitLab Flow" avec branches d'environnement, où staging joue le rôle d'environnement de stress test et de pré-production continue. Les fonctionnalités sont développées dans la branche develop, puis promues progressivement vers staging et main via des Pull Requests.
Le modèle GitLab Flow
GitLab Flow introduit une idée simple : On structure le flux autour des environnements de déploiement
Exemple typique :
feature → develop → staging → main
↓ ↓
tests, CI lourdsintégration dev, staging → pré-prod / validation et main → prod
C'est exactement le modèle que j'utilise
feature/*
↓
develop
↓ (tests classiques)
staging
↓ (tests lourds, perf, intégration complète)
main
↓
tag = releaseRôle de chaque branche
→ staging : branche de test, utilisée pour valider avant la mise en production
→ main : branche de production, version la plus stable du projet
Dans ce modèle, le code circule de manière unidirectionnelle pour garantir que ce qui est testé en Staging est exactement ce qui arrive en Production
Flow Git - Process de fusion par branche
develop → feature/xxx
feature/xxx → PR → develop
develop → PR → staging
staging → PR → maindevelop (Source de vérité agile):
On crée des branches depuis develop, ensuite on les y fusionnent via Pull Request. C'est le "bac à sable" d'intégration continue
staging (Validation de performance):
On fusionne vers staging uniquement quand un lot de fonctionnalités est stable. Cet environnement doit être le miroir de la prod
main (Production immuable):
On fusionne staging vers main par un Tag Git (ex: v1.2.0), Le tag déclenche le pipeline final. L'utilisation de tags assure la traçabilité complète des versions
Avantages
Isolation des Workflows: Les tests lourds (K6) ne ralentissent pas le cycle quotidien de dev, car ils ne tournent que sur la branche staging
Promotion du code: On valide l'artefact technique (le code testé) à chaque étape, réduisant ainsi les risques d'erreurs "de dernière minute" en production
Sécurité par Tag: En restreignant le déploiement sur main aux seuls tags, on évite les accidents lors de simples fusions de branches
Mise en place des régles dans Github
Définition des règles par branches
| Branche | Require a PR before Merging | Require Status Check to Pass | Linear History | Block force pushes | |
|---|---|---|---|---|---|
| develop | Oui | Oui → Build and test | Non (optionnel) | Non (optionnel) | |
| staging | Oui | Oui → ci-staging | Oui | Oui | |
| main | Oui | Oui → Prod Build, Analyze and Deploy | Oui | Oui | |
Rulesets Options
|
|||||
Une fois mis en place, il sera impossible de casser prod par erreur
Configurations Github
Depuis votre projet Github, allez dans Settings, depuis le menu General, cliquez dans le menu Rules et puis Rulesets
Vous verrez alors la liste de toutes les règles définies pour le repository. Si vous n'en avez pas, cliquez sur le bouton
Sélection des options (develop)
Donnez un nom au ruleset: protect-develop et indiquer la/les branches où appliquer ces règles (target Branch): ici pour develop
Si vous appliquer une autre stratégie, vous pouvez définir plusieurs branches cibles
Restricted access Branch:
Restrict creations: Empêche de créer la branche
Restrict update Seul moi, et les personnes autorisée
pouvons mettre à jour
Restrict deletions: Empêche de supprimer la branche
Require linear history: Optionel (sur develop)
Indiquez les règles pour les PR
Require a PR before Merging + possibilité d'ajouter un "reviewer" (cela pour être vous)
Require Status Check to PassAprès avoir coché la case, cliquez sur Add checks, cliquez ensuite sur Show additional settings
Entrez le nom du job de votre workflow dans le champs, il doit proposer l'option pour valider l'étape
Block force pushes → empêche les push forcés
Vérifications finales
Après sauvegarde, essayer de faire:
- PR sur une branche sans CI
Si → refusé/error: c'est verrouillé correctement
Exemple de refus Git, après avoir appliqué les rulesets
$ git push origin develop
remote: error: GH006: Protected branch update failed for refs/heads/develop.
remote: error: Changes must be made through a pull request.
To github.com:username/repo.git
! [remote rejected] develop -> develop (protected branch hook declined)
error: failed to push some refs to 'github.com:username/repo.git'