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
            Excel Tricks Infographic by STL Training