Mauvaises pratiques observées

1. Des Releases mal nommées

Dès lors que la personne qui crée les Releases n’a pas appréhendé totalement la nature de ces objets, et si en particulier, elle commet l’erreur d’y voir une version d’une application au lieu d’un projet, leur simple nommage peut déboucher sur de mauvaises pratiques.

La première étant de donner le nom de l’application sans numéro de version.

Puisqu’une Release est un projet de test, il est nécessaire de mettre en œuvre un ensemble de Releases pour suivre l’historique d’une application tout au long de sa vie, de son chantier de Constructionconstruction jusqu’à sa Mise hors servicemise hors service. Historique d’une application

Dès lors, nommer ces Releases successives de manière arbitraire, sans numéro de version, devient aléatoire.

Il est donc relativement évident que si nous pouvons utiliser le nom de l’application produite comme préfixe de nom de Release, un suffixe est nécessaire.

Mais que faire si aucune gestion de version n’est mise en place ? Utiliser une date comme suffixe du nom de la Release ?

Nous déconseillons cette pratique, car par définition, une date peut glisser. Or, il conviendra d’éviter de renommer les Releases sans avoir une norme stable..

Il est vraiment impératif d’établir une règle de nommage des Releases sous la forme...

Pour consulter la suite, découvrez le livre suivant :
couv_EPALMQC.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
Définitions :
Suivant
Customisation conseillée