Show Menu
Cheatography
  1. Home >
  2. Cheat Sheets >

Cycle de développement Oxygen Cheat Sheet by [deleted]

Les différentes phases de traitement d'un ticket JIRA de la prise en charge jusqu'à la clôture.

1 - Création d'un workspace

Convention de nommage du workspace
Exemple
[feat|­fix­|do­c|p­atc­h]-­{de­scr­ipt­ion­}-{­JIRA}
feat-a­dd-­new­-fe­atu­re-­OXY­-0000
 
fix-bu­g-o­f-a­t-c­rea­tio­n-t­ime­-OX­Y-0000
Pour chaque tâche à traiter un workspace doit obliga­toi­rement être crée.

feat : Nouvelle foncti­onn­alité
fix : Correction d'une anomalie
doc : Amélio­ration de la docume­ntation
patch : Patch appliqué sur une branche de release*

La descri­ption doit permettre de donner une vision globale du dévelo­ppement qui sera effectué

* Cas partic­ulier

4 - Tests unitaires

Dévelo­ppement terminé ? Ajustez vos test unitaires.
Pour une feat, ajoutez de nouveaux tests unitaires et vérifier que votre couverture de tests dépasse 80%.
Pour se faire retournez en phase 2 - Tests unitaires

7 - Remise à niveau depuis develo­pment

Commande
git commit --amend
Le merge depuis develo­pment ne se fait que dans 2 cas :
 ­ - Bitbucket détecte un conflit
 ­ - la compil­ation de la feat échoue suite à un BC

Une fois le merge commité, il convient de revenir à la Phase 4 - Tests unitaires .
  

2 - Tests unitaires

Pour toute tâche de type fix (anomalie constaté sur le produit) portant sur du code JAVA (service, util, action élémen­taire, process, ...), la première chose à faire avant le dévelo­ppement d'un fix est la création d'un test unitaire qui reproduit le cas énoncé dans le jira.

Ce test unitaire doit être en erreur à l'exéc­ution et valide le fait que l'erreur est bien reprod­uct­ible.

5 - Tests runtimes

Ces tests sont manuels et ne nécessite pas de code. Ils servent à valider que le dévelo­ppement réagit bien avec l'ensemble des composants déployés sur le système.

Dans le cas ou des anomalies seraient identifié, il faudra retourner à la phase 2 - Tests unitaires afin de corriger l'anomalie constatée.

8 - Prise en charge des commen­taires

Toutes modifi­cations de code suggérées par le commen­taire d'un relecteur doit faire l'objet d'un commit respectant le nommage de la phase 3 - Dévelo­ppement

Si le commen­taire demande une modifi­cation du code, revenir à la phase 4 - Tests unitaires

Tips

Référence
poussez la branche de feat le plus tardiv­ement possible, si possible uniquement lors de la mise en PR. Cela permet de modifier facilement son historique git (amend de commit, rebase intera­ctif, ...)
  

3 - Dévelo­ppement

Nommage des commits
{JIRA}: {desc1}
 
 ­ ­ ­ ­ ­ ­ ­ ­ ­ ­{desc2}
 
 ­ ­ ­ ­ ­ ­ ­ ­ ­ ­{...}
 
 ­ ­ ­ ­ ­ ­ ­ ­ ­ ­{descn}
Les messages de commit doivent décrire se qui est fait dans le commit et non ce qui doit être fait pour la tâche.

En cours de dévelo­ppe­ment, si la compil­ation échoue, il convient de mettre à jour la branche du repository concerné avec dévelo­ppement en suivant la procédure en Phase 7.

Une fois le dévelo­ppement terminé, retour en 2 -Tests unitaires

6 - Mise en Pull Request

Commande
workspace pr
Modifier la pr repository principal pour inclure une descri­ption complète des modifi­cations apportées.

Modifier la pr de tout repository contenant des modifi­cations justifiant une explic­ation.

9 - Merge sur la branche de dévelo­ppement

Convention de nommage du commit
 
 
{Descr­iption}
 
 
{JIRA}
Ce message doit être positionné lors de l'ouve­rture de la pop-up de merge par Bitbucket
 

Metadata

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          User and System Interfaces Cheat Sheet
          Project organisation Cheat Sheet