Que ce soit pour ces termes ou pour d’autres, c’est à l’équipe à s’aligner et pas à toi à faire l’interprète.
Il y a deux possibilités, soit les gens s’alignent sur le sens d’un mot, soit ils le requalifient par un contexte.
Je suis confronté au quotidien à des termes employés avec des compréhensions ou des implications différentes selon les équipes, individus, secteurs, métiers…,
Face à cela, j’aimis en place un « glossaire contextuel ». Je demande simplement à chaque partie d’y définir chaque terme et si on se retrouve à devoir ajouter une définition différente pour un même terme, alors il est demandé pour chaque instance du terme de remplir la colonne « contexte ».
De cette manière, on ne « force » pas les différents usage(rs) à devoir changer, on montre les différences.
Et ce sont les « usagers » eux-mêmes qui soit chercheront à s’adapter (mais ça sera leur choix) ou à être plus précis, en n’utilisant plus le terme « seul » mais en précisant bien le contexte.
Puisque les parties ne sont plus « bloquées » par l’obligation d’un choix, chaque définition devient alors le prétexte d’un échange intéressant pour comprendre la définition de l’autre, pour comprendre son contexte, et peut-être réunir ces deux contextes, ou accepter les différences.
Maintenant pour en venir aux 2 mots.
Une release, une livraison, une publication, c’est (pour moi) le moment où une « version » est fixée.
Si on modifie encore quelque chose, c’est que c’est pour la version suivante.
On peut penser à un dictionnaire par exemple, on livre l’édition 2023, il est envoyé en impression. On ne peut plus revenir dessus.
Si on doit faire des corrections, on fera un addendum, un erratum ou on attend l’édition suivante.
La release est un « repère » dans la ligne de vie du produit.
Le déploiement, c’est la mise à disposition un groupe d’utilisateurs.
Le dictionnaire arrive chez le relecteur avant publication.
Le dictionnaire arrive en magasin pour qu’il soit acheté et lu par les clients.
Ce qui peut être « ambigu » en développement, c’est qu’on met en place des pratiques de déploiement continu ou des features flag. Parce qu’on rend les principes de déploiement et de release tellement atomiques, petits, fréquents que les concepts s’entremêlent.
En développement continu, chaque déploiement suit une release qui contient un minimum de changement par rapport à la release précédente.
Quand on utilise les features flag, on déploie des éléments qui ne seront pas « actifs » et qui ne seront pas perçus comme « déployés » par les utilisateurs alors qu’ils le sont. Il y a lieu alors d’ajouter le concept d’activation.
Et si je reprends ma petite explication ci-dessus, ce sont « mes définitions » l’important ce n’est pas de savoir si j’ai tort ou raison, mais bien de les comparer à celles des autres.
