Workflow Git

README.md

Ceci est une proposition de workflow visant à fluidifier les déploiements et le travail autour de Git dans les petites équipes.

Il s'agit d'une base de travail à adapter à chaque contexte. Par exemple ici Jira et Bitbucket sont utilisés, mais les concepts sont adaptables à d'autres outils équivalents.

Le but étant d'homogénéiser les méthodes de travail et d'assurer la qualité des livrables en favorisant la collaboration entre les développeurs.

Workflow.md

La branche principale de chaque dépôt Git est nommée main et sert de référence pour connaître à tout moment la couverture fonctionnelle de l’application.

---

Mettre en production

Déployer sur le serveur

Pour déployer sur le serveur de production, un pipeline est créé automatiquement lors d’un push sur la branche main.

Il suffit alors de déclencher l’étape nommée “Déploiement Prod“ pour lancer le déploiement du code (normalement déployé et testé sur le serveur de Preprod auparavant).

Annoter le code avec la date en mise en production

Lors d’une mise en production, un tag est ajouté sur le dernier commit de cette branche (par exemple via la commande git tag $(date '+%Y-%m-%d') puis git push origin --tags) pour annoter l’historique et pouvoir ainsi retrouver chaque mise en production à l’avenir.

Note

On peut également utiliser un tag flottant réutilisable git tag -f latest (noter le flag -f pour forcer l'écrasement du tag s’il existe déjà) pour pouvoir facilement revenir à cette version à l’avenir sans avoir à chercher le tag unique correspondant.

---

Effectuer un rollback

Si un déploiement apporte des régressions ou des bugs, il peut être critique d’effectuer un rollback rapidement.

Dans ce cas il suffit de déployer une version précédente de l’application

Sauvegarder l'état de la branche

Comme on va réinitialiser la branche main à un état précédent, il convient d’en faire une sauvegarde temporaire en la dupliquant :

git checkout main # On se met sur la branche principale
git pull # On s'assure d'être à jour
git checkout -b main_$(date '+%Y-%m-%d') # On crée une copie de la branche à jour
git checkout main # On revient sur la branche principale

Revenir à un état précédent

On peut alors revenir à l'état correspondant à la dernière mise en production :

git checkout main
git reset --hard latest
git push origin +main

Déployer sur le serveur de production

Une fois la branche réinitialisée sur le dépôt distant, elle peut alors être déployée via le pipeline habituel.

Pour cela, un pipeline doit être déclenché pour pousser la branche main (qui a été rollback) en production.

Revenir à la version de travail

Une fois le rollback correctement effectué et déployé, on peut récupérer notre version de travail afin d’y apporter les corrections nécessaire.

Pour cela il suffit de récupérer notre branche sauvegardée précédemment :

git checkout main_$(date '+%Y-%m-%d')
git branch -d main # On supprime la branche principale pour pouvoir la remplacer
git branch -m main_$(date '+%Y-%m-%d') main # On renomme notre branche
git push --force origin main # On remplace la branche distante

---

Prise en charge d’un ticket

Une fois qu'un ticket vous est assigné, vous pouvez commencer à travailler sur une branche dédiée, afin de ne pas impacter le travail des autres et de pouvoir tester et valider chaque besoin de façon distincte et isolée.

Créer la branche

Lors de la prise en charge d’un nouveau ticket, une branche est créé en reprenant son type et son identifiant (et idéalement un court descriptif), par exemple bug/ABC-42-titre-tronque-sur-page-accueil.

Ce nom peut être généré automatiquement — et la branche créée — par Jira dans le menu “Create branch“ du ticket.

-> <-

Attention, pour s’assurer de suivre ce format il faut respecter deux conditions :

• Passer l’interface de Jira en anglais (via vos paramètres de profil), autrement le vocabulaire utilisé sera en français

• Mettre à jour et sauvegarder le format dans les réglages de cette option (roue crantée à droite)

-> <- -> <-

Note : vous pouvez remplacer Issue summary par Issue summary short si les intitulés des tickets sont trop longs

Pour pouvez également créer la branche manuellement en utilisant le nom proposé par Jira, par exemple :

git checkout main
git pull
git checkout -b bug/ABC-42-titre-tronque-sur-page-accueil

Assurez-vous bien d'être à jour avec les dernières mises à jour de la branche de référence pour limiter les conflits dans le futur et vous éviter de faire un travail qui a peut-être déjà été fait par un collègue.

Automatisations Jira

En respectant ce format, Jira pourra alors automatiser certaines transitions de ticket.

Par exemple :

• Passer le statut à “En cours“ une fois la branche créée (via Jira ou manuellement, une fois poussée sur le repo distant)
• Passer le statut à “En attente de validation“ une fois une PR/MR créée
• Passer le statut à “Preprod“ une fois la branche de travail mergée sur main (normalement une fois la PR/MR validée)
• Passer le statut à “Déployé en prod“ une fois la branche main contenant ce travail déployée en production

Note

Note : Les abréviations PR (pull request) et MR (merge request) sont ici utilisées de façon interchangeable, malgré les nuances techniques, afin d'être applicables dans un maximum de cas.

Nommer ses commits

Bien nommer ses commits permet de comprendre plus facilement l’historique, surtout lorsqu’ils se retrouvent sur la branche principale : lors d’un retour en arrière ou de l’analyse d’un problème il est alors plus facile de retrouver un commit connu ou de comprendre ce qu’un commit inspecté vise à produire.

Évitez donc les noms génériques comme “fix“, "update" ou “wip“ et insérez autant de contexte que possible. Par exemple : “fix(frontend): add missing icon in home page header“ ou “chore(backend): update Composer deps“.

Note

Vous pouvez vous inspirer de Conventional Commits pour convenir d’un format qui convient à votre équipe et son fonctionnement.

---

Faire valider son code

Une fois votre travail terminé en local et poussé (git push) sur le dépôt distant, vous pouvez alors demander la validation du code à vos collègues afin de permettre plusieurs choses :

• qu’un moins deux personnes connaissent le fonctionnement de chaque fonctionnalité
• que vous n’ayez pas oublié un détail ou un potentiel effet de bord dans votre implémentation
• que la façon de faire soit compréhensible par un humain autre que vous-même (si vous êtes humain, bien entendu)
• qu’en cas de problème à l’avenir, au moins deux personnes soient capables d’intervenir rapidement (si vous voulez avoir le droit de partir en vacances ou d'être malade, par exemple)

Créer une pull request

Sur la page des Pull Requests, cliquez sur le bouton “Create pull request“ :

-> <-

Sélectionnez alors votre branche comme source et main comme cible. Vous pouvez compléter la description afin d’apporter des détails et du contexte à votre travail.

Le ticket correspondant devrait alors passer au statut “En attente de validation“ automatiquement. Si ce n’est pas le cas, pensez à le faire manuellement pour que vos collègues sachent que leur avis est attendu.

Valider le code d’un collègue

Lors de la validation du code d’un collègue (personne n’est au-dessus d’une revue de code et tout le monde peut valider le code des autres), concentrez-vous sur les aspects fonctionnels en priorité.

Important

En cas de désaccord sur une méthode d’implémentation, échangez et argumentez (courtoisement, bien entendu) vos points de vue respectifs dans l’objectif d’arriver à un accord. Si nous n’y arrivez pas, le responsable technique aura le dernier mot.

Les questions de syntaxe doivent avant tout être gérés par des outils automatiques comme un linter.

Important

En cas de débat ou désaccord sur la syntaxe, reportez la question à plus tard si possible (tant que cela n’a pas d’impact fonctionnel) en ouvrant un nouveau ticket dédié par exemple.

Quand il faut corriger des choses

Une fois votre revue de code faite, s’il faut absolument corriger des choses, passez le ticket correspondant à l'état précédent (“En cours“) pour signaler au collègue en charge de son développement qu’il doit re-travailler dessus.

Quand tout est bon

Si tout vous semble correct vous pouvez signaler votre approbation du travail de votre collègue sur la PR/MR et envoyer le ticket en phase de test (passage manuel au statut “En attente de test“).

---

Tester un ticket

Chaque branche de travail active est déployée et testable sur un sous-domaine unique.

Une fois que la branche est supprimée, le déploiement correspondant est supprimé.

Lorsqu’un(e) testeur/euse prend en charge un ticket (statut “En attente de test“) il le signale (passage au statut “En cours de test“).

Il/elle exécute alors les tests appropriés pour s’assurer que la fonctionnalité attendue fonctionne de façon adéquate.

Quand les exigences ne sont pas encore atteintes

Si quelque chose ne va pas, des sous-tickets sont créés pour chaque problème à gérer et le ticket est repassé au statut “En cours“.

Le process classique recommence alors (et le code alors modifié doit être à nouveau validé).

Quand tout est bon

Une fois la fonctionnalité (ou correction de bug) validée, le ticket peut alors être passé à l'état “Test OK“.

---

Intégrer la branche au reste du projet

Le responsable technique peut alors procéder au merge de la branche pour lancer le déploiement d’une nouvelle version sur le serveur de préprod et intégrer le travail à la prochaine mise en production.

La branche de travail peut alors être supprimée.

Note

Une fois le code intégré à la branche main, un déploiement sera fait sur le serveur de préprod. Cela permet alors de procéder aux tests d’intégration pour s’assurer que le déploiement automatique se fait bien, ainsi que les migrations de données.

Annuler l’intégration

Lors d’un merge, un commit spécifique est ajouté pour indiquer les modifications. Si vous souhaitez annuler une intégration vous pouvez annuler le commit en question. Par exemple s’il s’agit du dernier commit sur main :

git checkout main
git revert # Vous invitera à éditer le message du commit de revert avec une valeur pré-définie
git push

---

Garder sa branche à jour tout au long du process

Attention à bien garder votre branche à jour avec main autant que possible pour éviter les conflits lors de ce merge final.

git checkout main
git pull
git checkout bug/ABC-42-titre-tronque-sur-page-accueil
git rebase main # Vous devrez peut-être gérer des conflits sur le code que vous avez modifié. Il en est de votre responsabilité de les gérer correctement
git push --force-with-lease

Cette responsabilité est la vôtre, pensez à mettre votre branche à jour régulièrement pour éviter de gérer trop de conflits d’un coup.

Warning

En cas de conflit lors du merge final, le responsable technique pourra se réserver le droit d’exiger des croissants frais en cas de manquement à vos devoirs.