github workflow

26
Github workow Gestion de projet tech

Upload: jim-laurie

Post on 19-Jul-2015

362 views

Category:

Internet


3 download

TRANSCRIPT

Github workflow Gestion de projet tech

Jim LAURIE @laurie_jim / hack1337

Gestion des sprints

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

milestone.

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

milestone. !- Bien nommer et documenter la milestone

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

milestone. !- Bien nommer et documenter la milestone: !- Créer les labels convenant au projet

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

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

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

Gestion des branchs

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

masterpreprod

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}

!

masterfront/landingPagefeature/linkProviders preprod

Feature development. !!- Bien nommer chaque commit !

> git commit -am ‘[{featureName}] description simple’

master

2 1

front/landingPagefeature/linkProviders 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

front/landingPagefeature/linkProviders 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

front/landingPagefeature/linkProviders 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

front/landingPagefeature/linkProviders preprod

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

D

front/landingPagefeature/linkProviders preprod

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

D

preprod

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.

masterfix/landingPagefix/linkProviders

D4

3

D

preprod

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

D4

3D

3

3

D

D

4

D

fix/landingPagefix/linkProviders preprod

master

D

fix/landingPagefix/linkProviders

Release. !!- Suppression des branchs de fix.

preprod

Release. !!- Suppression des branchs de fix.

master

D

preprod

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

D

D

preprod

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

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/

MERCI.