Github workflow

591 vues

Publié le

Conf workflow git/github

Publié dans : Internet
1 commentaire
2 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
591
Sur SlideShare
0
Issues des intégrations
0
Intégrations
24
Actions
Partages
0
Téléchargements
20
Commentaires
1
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Github workflow

  1. 1. Github workflow Gestion de projet tech
  2. 2. Jim LAURIE @laurie_jim / hack1337
  3. 3. Gestion des sprints
  4. 4. Milestones. ! ! ! - Pour chaque sprint on crée une nouvelle milestone.
  5. 5. Milestones. ! ! ! - Pour chaque sprint on crée une nouvelle milestone. ! - Bien nommer et documenter la milestone
  6. 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. 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. 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. 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. 10. Gestion des branchs
  11. 11. Branch static. ! ! ! ! ! ! ! ! 2 branchs static: - preprod - production (master) preprod master
  12. 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. 13. feature/linkProviders front/landingPage preprod Feature development. ! ! - Bien nommer chaque commit ! > git commit -am ‘[{featureName}] description simple’ master 2 1
  14. 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. 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. 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. 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. 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. 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. 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. 21. master D fix/linkProviders fix/landingPage Release. ! ! - Suppression des branchs de fix. preprod
  22. 22. Release. ! ! - Suppression des branchs de fix. master preprod D
  23. 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. 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. 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. 26. MERCI.

×