Tech & DevOps HubEspace Tech & DevOps:
Explorez le monde du Dev, du Cloud et des outils DevOps à travers nos articles et discussionsExplore the world of development, the cloud and DevOps tools
Mise en place de workflows GitHub Actions pour automatiser la promotion de code entre branches (develop → staging → main) via des PR auto-créées. Couvre les stratégies envisagées, l'implémentation, les permissions requises et l'auto-merge
La promotion de branche CI/CD avec GitHub Actions automatise le passage de code entre environnements en déclenchant des workflows basés sur des événements Git. Elle permet de valider le code, construire des artefacts et déployer de manière sécurisée.
Le contexte
Actuellement, le flux est le suivant: Feature → PR vers develop → merge après validation develop → staging → main, lancement manuel des PR, avec validation CI à chaque étape
Contraintes à respecter suivant ma strategie git flow: → Aucun push direct → Respect strict des protections de branches → Déclenchement uniquement après merge pour éviter les doubles exécutions CI
Ce processus étant chronophage, nous allons l'automatiser avec les conditions suivantes : → Déclenchement après push sur develop, activer l'auto-merge → Création automatique d'une PR vers staging (idem staging → main)
Flux:
feature branch
↓
PR → develop
↓ (CI OK)
merge
develop mis à jour
↓
PR → staging
↓ (CI OK)
merge
staging mis à jour
↓
PR → main
↓ (CI + tests OK)
merge manuel
Stratégies envisagées
Pour automatiser le passage entre branches, plusieurs approches sont possible, voyons cela rapidement:
Aucun push, donc respect des Branch Protection Rules
Offre un contrôle total sur la logique
Ce qu'il faut savoir
Les PR créées avec le GITHUB_TOKEN, par défaut ne déclenchent pas les workflows Il s'agit d'un mécanisme de sécurité pour éviter les boucles infinies.
Deux solutions posssibles:
Accepter que la PR-auto n'ait pas accès à la CI et ne déclencher la CI qu'après le merge
Utiliser un Personal Access Token (PAT). Dans ce cas, les events peuvent déclencher des workflows
Configuration Github
1. Créer le PAT
1. Créer le token: Cliquer sur votre profil: dans le menu, choisir settings Aller en bas de page: Cliquez sur Developer Settings Cliquez sur "Personal access tokens" et choisir "Fine-grained tokens"
2. Donner un nom au token: GH_PAT Le token commence par github_pat_****
3. Donnez lui les permissions: → Le limiter au repository concerné en le choissant dans la liste de vos projets
Techniquement: la commande "git push" ne déclenche rien ; C'est le merge de la PR feature, vers develop, qui déclenche un push sur developqui, à son tour, lors du push, lancera le workflow "PR-auto"
Pour tester le mécanisme complet, et suivant ma stratégie Gitlow, la procédure est de créer une branche feature, ouvrir une Pull Request vers develop puis la fusionner.Le push résultant sur develop déclenchera automatiquement la promotion vers staging.
Vue depuis les Actions
Merge pull request #184 from val7304/staging-to-main
Prod Build, Analyze and Deploy Flashcards App #102: Commit f505634 pushed by val7304 main Feb 23, 1:43 AM GMT+1 4m 30s
Promote staging → main
Prod Build, Analyze and Deploy Flashcards App #101: Pull request #184 synchronize by val7304 staging Feb 23, 1:37 AM GMT+1 4m 23s
Merge pull request #186 from val7304/develop-to-staging
CI - Staging #155: Commit f7134b7 pushed by val7304 staging Feb 23, 1:37 AM GMT+1 7m 22s
Promote develop → staging
CI - Staging #154: Pull request #186 synchronize by val7304 develop Feb 23, 1:32 AM GMT+1 4m 26s
Merge pull request #176 from val7304/develop
CI - Staging #149: Commit c94e694 pushed by val7304 staging Feb 22, 10:49 PM GMT+1 7m 12s
Merge pull request #175 from val7304/feature/pr-auto
CI - Develop #109: Commit 0648c2f pushed by val7304 develop Feb 22, 10:40 PM GMT+1 2m 24s
Bonus : activation de l'auto-merge (only develop → staging)
On ajoute l'auto-merge pour finaliser automatiquement la PR entre develop → staging, après validation des checks
Modification du workflow, ajouter en fin de script:
gh pr merge "$PR_NUMBER" \
--auto \
--merge
Cette commande active le mode "auto-merge" et attend que tous les "required checks" de la CI, soient validés
Flux final
feature → develop
↓
PR auto
↓
CI OK
↓
merge auto
Dans l'UI GitHub, durant tout le déroulé du PR on voit bien: La PR en état "Auto-merge enabled", et les options GitHub habituelles restent disponibles:
Create a merge commit: conserve tout l'historique des commits avec un commit de fusion.
Squash and merge: regroupe tous les commits de la PR en un seul commit.
Rebase and merge: rejoue les commits de la PR proprement sans commit de merge.
Disable auto-merge désactive la fusion automatique de la PR.
Ces options restent disponibles durant toutes les phases de vérifications de la PR, on peux donc encore modifier le mode.
Require approval Si activé, le merge restera bloqué sans validation humaine
Si la branche cible (staging) exige:
reviews obligatoires checks obligatoires → l'auto-merge attendra leur validation
Modifier les permissions et activer l'auto-merge
1. Modifier les permissions du token PAT: Contents: read and write
2. Configuration Github Depuis le projet Settings, activer:
You can allow setting pull requests to merge automatically once all required reviews and status checks have passed
Allow auto-merge
Waits for merge requirements to be met and then merges automatically.
Résultat : PR créée automatiquement CI exécutée sur staging Merge automatique si tous les checks sont valides
L'auto-merge ne déclenche pas la CI. Il attend uniquement que les checks configurés soient validés
Même si nous avons configuré l'auto-merge, l'option manuelle durant la phase où le PR tourne reste disponible via le menu-liste de merge
Résultat global
→ La Promotion est automatisée, la validation CI est exécutée à chaque étape. → Le merge automatique est contrôlé. Le pipeline est fiable et traçable
PR #203 staging → main CI Production #107 Merge manuel
Deploy exécuté (#108)
En résumé
develop → staging:auto-merge → permet une intégration rapide et continue des features dans l'environnement de validation sans intervention humaine systématique.
staging → main: garde une validation manuelle qui ajoute un contrôle final avant production pour s'assurer de la stabilité, conformité métier, sécurité et éviter qu'un incident atteigne l'environnement live
Point important Le repository reste la source de vérité en cas de divergence liée aux mises à jour CI/CD.
Dans l'article suivant, nous verrons comment améliorer le Dockerfile, nous parlerons aussi du Dockerfile.debug et ce qu'il peux nous apporter. Enfin nous verrons comment Actuator peux nous aider encore + à diagnostiquer les problèmes (à défaut de ne pouvoir entrer dans le container)
Naviguez entre les articlesBrowse through the articles