Le document décrit un workflow de gestion de projet utilisant GitHub, soulignant l'importance de créer des milestones pour chaque sprint, bien documenter les tâches et suivre les développements par des branches spécifiques. Il insiste sur la nécessité de relectures et de gestion rigoureuse des pull requests par un gatekeeper pour garantir la qualité du code. Enfin, il propose des bonnes pratiques pour le développement, le tagging et la gestion des versions.

1. Github workflow
Gestion de projet tech

2. Jim LAURIE
@laurie_jim / hack1337

3. Gestion des
sprints

4. Milestones.
!
!
!
- Pour chaque sprint on crée une nouvelle
milestone.

5. Milestones.
!
!
!
- Pour chaque sprint on crée une nouvelle
milestone.
!
- Bien nommer et documenter la milestone

6. Milestones.
!
!
!
- Pour chaque sprint on crée une nouvelle
milestone.
!
- Bien nommer et documenter la milestone:
!
- Créer les labels convenant au projet

7. Milestones.
!
!
!
- Pour chaque sprint on crée une nouvelle
milestone.
!
- Bien nommer et documenter la milestone:
!
- Créer les labels convenant au projet
!
- Ajouter une issue pour chaque tâche, il faut
qu’elle soit bien détaillée. Plus il y a d’issues, plus
on a de la visibilité sur l’avancement du sprint.
> Lier l’issue à la milestone
> Mettre les labels correspondants
> Assigner l’issue à une personne

8. Milestones.
!
!
!
- Pour chaque sprint on crée une nouvelle
milestone.
!
- Bien nommer et documenter la milestone:
!
- Créer les labels convenant au projet
!
- Ajouter une issue pour chaque tâche, il faut
qu’elle soit bien détaillée. Plus il y a d’issues, plus
on a de la visibilité sur l’avancement du sprint.
> Lier l’issue à la milestone
> Mettre les labels correspondants
> Assigner l’issue à une personne

9. Milestones.
!
!
!
- Pour chaque sprint on crée une nouvelle
milestone.
!
- Bien nommer et documenter la milestone:
!
- Créer les labels convenant au projet
!
- Ajouter une issue pour chaque tâche, il faut
qu’elle soit bien détaillée. Plus il y a d’issues, plus
on a de la visibilité sur l’avancement du sprint.
> Lier l’issue à la milestone
> Mettre les labels correspondants
> Assigner l’issue à une personne

10. Gestion des
branchs

11. Branch static.
!
!
!
!
!
!
!
!
2 branchs static:
- preprod
- production (master)
preprod master

12. Branch feature.
!
!
!
!
- Chaque feature doit avoir une branch
spécifique.
!
- Ne pas séparer le front et le back
- Nomenclature à respecter:
{type}/{featureName}
!
- Chaque nouvelle feature part de
la branch preprod.
> git checkout preprod
> git checkout -b {branchName}
!
feature/linkProviders front/landingPage preprod master

13. feature/linkProviders front/landingPage preprod
Feature development.
!
!
- Bien nommer chaque commit !
> git commit -am ‘[{featureName}] description simple’
master
2 1

14. feature/linkProviders front/landingPage preprod
Feature development.
!
!
- Bien nommer chaque commit !
> git commit -am ‘[{featureName}] description simple’
!
- Une fois qu’une feature est fini, le développeur de
la feature soumet une pull request de sa branch
sur la branch preprod.
!
- Seule une personne accepte les PR ! (gatekeeper)
Il faut nécessairement une double relecture afin de
corriger des fautes et garantir la qualité du code
qui sera mis en production.
master
2 1
D

15. feature/linkProviders front/landingPage preprod
Feature development.
!
!
- Bien nommer chaque commit !
> git commit -am ‘[{featureName}] description simple’
!
- Une fois qu’une feature est fini, le développeur de
la feature soumet une pull request de sa branch
sur la branch preprod.
!
- Seule une personne accepte les PR ! (gatekeeper)
Il faut nécessairement une double relecture afin de
corriger des fautes et garantir la qualité du code
qui sera mis en production.
!
- Lors du merge de la branch, les autres branchs
doivent pull la branch preprod afin d’être à jour et
de traiter au plus vite les possibles conflits.
> git pull origin preprod
master
2 1
2
D
2

16. feature/linkProviders front/landingPage preprod
Feature development.
!
!
- Bien nommer chaque commit !
> git commit -am ‘[{featureName}] description simple’
!
- Une fois qu’une feature est fini, le développeur de
la feature soumet une pull request de sa branch
sur la branch preprod.
!
- Seule une personne accepte les PR ! (gatekeeper)
Il faut nécessairement une double relecture afin de
corriger des fautes et garantir la qualité du code
qui sera mis en production.
!
- Lors du merge de la branch, les autres branchs
doivent pull la branch preprod afin d’être à jour et
de traiter au plus vite les possibles conflits.
> git pull origin preprod
master
2 1
2
D
D
2

17. Fix / Hot fix.
!
!
- Suppression des branches des features
développés et mergés.
> git checkout preprod
> git pull origin preprod
> git push origin {branchName} —delete
> git branch -D {branchName}
master
feature/linkProviders front/landingPage preprod
D

18. Fix / Hot fix.
!
!
- Suppression des branches des features
développés et mergés.
> git checkout preprod
> git pull origin preprod
> git push origin {branchName} —delete
> git branch -D {branchName}
!
- Une fois que toute les features que l’on veut
sortir sont sur la branch preprod, il faut les
tester et s’assurer que tout fonctionne bien.
master
preprod
D

19. Fix / Hot fix.
!
!
- Suppression des branches des features
développés et mergés.
> git checkout preprod
> git pull origin preprod
> git push origin {branchName} —delete
> git branch -D {branchName}
!
- Une fois que toute les features que l’on veut
sortir sont sur la branch preprod, il faut les
tester et s’assurer que tout fonctionne bien.
!
- Lors d’un retour à traiter la personne concerné le
traite sur une nouvelle branch de fix.
fix/linkProviders fix/landingPage preprod
master
D
4
3
D

20. Fix / Hot fix.
!
!
- Suppression des branches des features
développés et mergés.
> git checkout preprod
> git pull origin preprod
> git push origin {branchName} —delete
> git branch -D {branchName}
!
- Une fois que toute les features que l’on veut
sortir sont sur la branch preprod, il faut les
tester et s’assurer que tout fonctionne bien.
!
- Lors d’un retour à traiter la personne concerné le
traite sur une nouvelle branch de fix.
!
- Le process reste le même que pour le
développement de feature.
master
fix/linkProviders fix/landingPage preprod
D
4
3
D
D
3
3
D
4
D

21. master
D
fix/linkProviders fix/landingPage
Release.
!
!
- Suppression des branchs de fix.
preprod

22. Release.
!
!
- Suppression des branchs de fix.
master
preprod
D

23. Release.
!
!
- Suppression des branchs de fix.
!
- Une fois que les bugs sont fixés et vérifiés, le
gatekeeper fait un commit en changeant les
numéros de versions là où il faut (package.json) et
ajout les modifications de la realese dans le
CHANGELOG.md.
> git commit -am ‘{numVersion}’
master
preprod
D
D

24. master
D
M
D
Release.
!
!
- Suppression des branchs de fix.
!
- Une fois que les bugs sont fixés et vérifiés, le
gatekeeper fait un commit en changeant les
numéros de versions là où il faut (package.json) et
ajout les modifications de la realese dans le
CHANGELOG.md.
> git commit -am ‘{numVersion}’
!
- Merge de la branch preprod sur master.
!
- Ajout d’un tag de version.
> git tag {version}
> git push origin {version}
!
- Après un merge sur master, on re teste mais cette
fois la version en production.
!
- Si un bug est relevé, on utilise le workflow précédent
(Fix / Hot fix) avec hotfix en préfix de branch.
preprod

25. Tips.
!
- Utiliser les lignes de command git
!
- 1 personne gère les PR ! (gatekeeper)
!
- Ne pas push des trucs qui marchent pas
!
- Commit sans modération
!
- Utiliser les commentaire de github
!
- Message explicite du commit
!
- 1 commit = qqchose en particulier
!
- Utiliser le .gitignore / .gitkeep
!
- Relire son code avant PR
!
- Double relecture pour la PR
!
- https://try.github.io
- https://education.github.com/

26. MERCI.