Comment démarrer une nouvelle version du produit et briser la compatibilité avec les versions précédentes
Il y a quelques jours, j’ai discuté avec mes collègues de nelio de l’avenir du plug – in de test A \/ B de nelio et de ses fonctionnalités et améliorations à venir. En tant que plate – forme de test A \/ B, le plugin doit être constamment mis à jour pour se tenir au courant des nouvelles versions de WordPress et s’assurer que tout fonctionne correctement. N’oubliez pas qu’il s’agit du premier plugin que nous avons lancé pour WordPress à la fin de 2013 et qu’il a évolué depuis. L’ajout de Gutenberg à WordPress ouvre de nouvelles possibilités de tests décentralisés. Cela soulève une question intéressante: devons – nous apporter des améliorations progressives à nos produits ou est – il préférable de commencer à zéro avec un nouveau produit qui tire pleinement parti des blocs WordPress?
Nous n’avons pas encore décidé de la voie à suivre, mais j’aimerais discuter des problèmes que pose la publication de nouvelles versions sans être compatibles avec les versions précédentes et de la façon dont nous pouvons atténuer ou éliminer ces problèmes. Par conséquent, aujourd’hui, je vais vous présenter deux solutions pour démarrer une nouvelle version du service en interrompant la compatibilité avec les versions précédentes afin que vos clients ne soient pas touchés par cette décision. Chris Lema a récemment mentionné sur son blog la compatibilité avec les versions précédentes, \
De la base de données. Changez l’API Cloud (si notre plug – in utilise l’API). Passer à un nouveau modèle d’entreprise, puis passer à un nouveau modèle de mise à jour, de fonctionnalité, etc. Par exemple, considérez notre service de test A \/ B. La situation générale est la suivante:
Vous pouvez créer des tests A \/ B sur le site Web. Fondamentalement, le test A \/ B consiste en la page que vous souhaitez tester, une ou plusieurs variantes de la page et les objectifs de conversion que nous essayons d’améliorer. Toutes ces informations sont stockées dans WordPress. La composante Cloud est chargée de surveiller l’accès aux sites Web qui utilisent le test nellio A \/ B. Comme Google Analytics, ce composant recueille des informations, les traite et produit des résultats sommaires. Et, comme Ga, ces données sont envoyées à l’aide d’un script trace. Enfin, il y a une vue dans le plug – in qui se connecte au Cloud via l’API. Cette vue extrait les résultats sommaires et vous montre des statistiques et des graphiques. Les plug – ins comme le test nellio A \/ B peuvent être modifiés de plusieurs façons, et si nous ne sommes pas prudents, l’un de ces changements pourrait entraîner un « plug – in déconnecté ». Par exemple, supposons que nous voulions \/ devions mettre à jour l’API Cloud. Dans ce cas, nous devons également mettre à jour le plug – in, car l’affichage des scripts de suivi et des résultats dépend de l’API. Par conséquent, une nouvelle API nécessite un nouveau plug – in. Mais le problème se pose: Cette nouvelle API signifie aussi que nos utilisateurs doivent la mettre à jour maintenant, car l’ancienne version de notre plug – in ne sera pas en mesure de communiquer avec la nouvelle API.
Maintenant, portez les chaussures de vos utilisateurs: un plug – in qui fonctionne parfaitement et qui ne fonctionne plus grâce à vos mises à jour dans le cloud. Pas très bien. Il n’y a pas de solution possible
Commentaires, installation active…) manquant, vous devez recommencer à zéro. Il s’agit d’une solution optionnelle: Nous avons lancé un nouveau produit et vous invitons à cesser d’utiliser l’ancien produit et à en acheter un nouveau. C’est ce que WordPress a fait (plus ou moins) Il y a quelques mois lors de la publication du plugin Gutenberg: vous décidez si vous souhaitez utiliser Gutenberg sur votre site en installant le plugin sur le site.
Démarrer une mise à jour pour arrêter la compatibilité avec une version précédente (opt – out) Une autre option est la méthode inverse, ou opt – out solution: publier une mise à jour pour arrêter la compatibilité avec une version précédente du produit et démarrer un nouveau produit en utilisant l’ancienne version. De cette façon, même si la nouvelle version n’est pas rétrocompatible, nous offrons aux utilisateurs une alternative pour que tout fonctionne comme ils sont habitués à le faire. En publiant une nouvelle version, tous les utilisateurs pourront la voir et la découvrir (effet wow). Toutefois, s’ils ne sont pas intéressés, nous leur donnerons également la possibilité d’utiliser la version précédente, qui sera publiée en tant que nouveau produit. Cette approche résout les deux problèmes que nous avons soulevés dans la solution précédente. D’une part, tous les utilisateurs sauront dès le premier jour que notre produit \/ Service a une nouvelle version et seront en mesure de voir et d’essayer les nouvelles.
D’autre part, et peut – être plus important encore, nous continuons de bénéficier de tout le travail accompli jusqu’à présent, car nous n’avons publié qu’une nouvelle version du produit consolidé. Vous conserverez la marque, les commentaires, les statistiques… Rien ne change, parce que tu ne commences pas à zéro. Comme vous pouvez l’imaginer, c’est la solution opt – out: chaque fois qu’un utilisateur met à jour un plug – in, il voit une nouvelle version (bien qu’il n’aime pas qu’il rompe la compatibilité avec la version précédente). Mais tu leur as aussi donné l’occasion de revenir dans le passé.
Installez la version du nouveau produit. C’est ce que WordPress a fait en décembre dernier, lorsqu’il a introduit l’éditeur de bloc dans sa dernière mise à jour et a donné aux utilisateurs la possibilité d’utiliser l’ancien éditeur en installant le plug – in Classic editor.
Détruire la compatibilité avec les anciennes versions n’est pas une mince affaire, car elle peut avoir un impact significatif sur vos utilisateurs. En règle générale, nous ne le recommandons pas. Mais parfois, c’est la seule option. Si cela est nécessaire, je vous suggère de mettre en œuvre l’une des deux solutions que nous voyons aujourd’hui. Avec eux, assurez – vous que vos utilisateurs ont un plan de sauvegarde afin que « tout soit comme avant » et que personne ne se plaigne de « choses cassées ». Bien sûr, en contrepartie, vous devez conserver deux produits (même si l’on suppose que la version « ancienne » est la moins entretenue), mais c’est le sujet d’un autre article.
Dites – moi, avez – vous déjà eu de tels problèmes? Comment avez – vous résolu ça? Que feriez – vous? Une image caractéristique de Dietmar Becker dans unsplash.