Déploiements par étapes pour les développeurs de plugins et de thèmes WordPress : Éviter une "version de clusterbug"
Publié: 2020-12-23Vous rappelez-vous la dernière fois que vous avez publié une nouvelle version de votre plugin ou thème WordPress pour découvrir rapidement que vous avez ajouté par erreur un nouveau bogue majeur qui s'est glissé dans vos fissures de séquence de test ?
Yoast SEO 3.0 a cassé de nombreux sites Web en 2015. Elementor 3.0 a fait de même cette année. Et ce ne sont que deux exemples de mon chef d'entreprises fantastiques dans notre espace avec plus de 100 employés et un personnel d'assurance qualité dédié (et non, ce n'est pas lié à la version 3.0, mais c'est peut-être un signe pour ignorer cette version dans votre logiciel ; )).
Que vous soyez un codeur ou un ingénieur logiciel autodidacte, un développeur indépendant ou que vous fassiez partie d'une grande boutique de plugins/thèmes, nous devons tous faire face à des bugs. C'est une partie inévitable du développement logiciel.
Peu importe les automatisations sophistiquées CI/CD/test que vous mettez en place, vous ne pourrez jamais tout tester. Le nombre de configurations de serveurs (PHP, MySql, cache, serveur web), de versions WP, de combinaisons de plugins et de thèmes… est infini.
Et c'est contre-intuitif. Plus vos produits deviennent populaires et stables, plus les chances d'une version redoutée de "Clusterbug" augmentent, ce qui épuisera votre support, peut avoir un impact significatif sur la confiance et la fidélité de vos clients et potentiellement nuire à la réputation globale de la marque.
Bien que vous ne puissiez pas éviter les bogues, vous pouvez, et devriez certainement, atténuer les risques autant que vous le pouvez.
Si vous avez un smartphone, vous avez probablement remarqué que certains de vos amis reçoivent des mises à jour Android/iOS des jours, des semaines, parfois même des mois avant que vous ne les receviez. Ce n'est pas une coïncidence, et non, ce n'est rien de personnel contre vous. Il s'agit d'un processus de déploiement progressif intentionnel appelé Staged Rollouts qui aide des entreprises comme Apple à expédier des mises à jour logicielles majeures à plus d'un milliard d'appareils.
Oui, un milliard !
Pouvez-vous même comprendre le degré de responsabilité qu'un chef de version chez Apple aurait sur ses épaules s'il devait pousser une mise à jour en direct sur 1,5 milliard d'appareils mobiles simultanément ? Je ne peux pas. Je parie qu'aucun homme sensé n'accepterait de porter une telle responsabilité.
Alors, comment fonctionne le mécanisme de déploiement par étapes ? Comment pouvez-vous le mettre en œuvre ? Et qu'attend WordPress.org ? Ce sont les sujets que je vais aborder ci-dessous.
Que sont les déploiements par étapes pour les plugins et thèmes WordPress ?
Les déploiements par étapes vous permettent de spécifier le nombre (ou le pourcentage) de sites Web sur lesquels vous souhaitez déployer une nouvelle version. Un mécanisme de déploiements par étapes vous permet de commencer votre cycle de publication avec une exposition limitée, puis de l'augmenter progressivement tout en surveillant le support et les commentaires, renforçant ainsi la confiance dans votre version pour vous et vos utilisateurs.
Quels sont les avantages des déploiements par étapes ?
Au lieu de risquer l'ensemble de votre base d'installation avec la publication de bogues potentiels, de conflits avec des plugins/thèmes tiers ou même de problèmes d'interface utilisateur/UX, vous pouvez publier des versions progressivement, en minimisant le nombre de personnes et de sites Web qui seront exposés à des problèmes inattendus. Une fois que vous aurez résolu tous les problèmes et bugs découverts au cours du processus de déploiement, la grande majorité de vos utilisateurs seront exposés à une version "mature" et beaucoup plus stable.
Nous utilisons des mises à jour continues pour garantir la qualité de nos nouvelles versions. S'il y a un problème avec une nouvelle version, nous pouvons l'identifier rapidement, et seul un petit sous-ensemble d'utilisateurs aurait été affecté.
John Turner, fondateur de SeedProd
L'utilisation de déploiements par étapes est LA meilleure pratique pour publier des logiciels de manière responsable - un processus suivi par de nombreuses entreprises (quelle que soit leur taille) en dehors de la bulle WP.
Il existe une grande opportunité pour la communauté WordPress de tirer parti des déploiements par étapes, sur lesquels je reviendrai dans un instant.
Les programmes bêta sont-ils similaires aux déploiements par étapes ?
La mise en place d'un programme bêta pour votre produit WordPress est un bon début, mais il est loin d'être aussi efficace que les déploiements par étapes, et il a un objectif et une dynamique fondamentalement différents.
À moins que votre plugin ou votre thème ne soit extrêmement populaire et ait une grande communauté, il est assez difficile de recruter un groupe bêta statistiquement suffisant, car seule une infime fraction des utilisateurs sera intéressée à se joindre. Même si vous excellez dans le recrutement d'un groupe décent de bêta-testeurs, vous devez compter sur leur disponibilité et leur bonne volonté pour tester le produit, puis espérer qu'ils feront l'effort supplémentaire de signaler les problèmes qu'ils trouvent.
Selon vous, combien de personnes verront tout au long de ce processus ? Pas beaucoup.
Les tests bêta sont un processus de pré-production dans lequel vos efforts de support sont entièrement contrôlés et les testeurs s'attendent à rencontrer des problèmes avec les versions bêta. Par conséquent, les attentes des testeurs en matière de qualité ne représentent pas le sentiment général de votre base d'utilisateurs.
De plus, un programme bêta responsable avertira ses testeurs d'éviter d'utiliser des versions bêta dans des environnements de production, de sorte que les tests bêta ne simulent pas vraiment des sites Web de production en direct.
Comment gérer une version de déploiement par étapes pour votre plugin ou thème WordPress ?
Dans le cadre de mes recherches sur les déploiements par étapes, j'ai eu la chance de rencontrer en ligne Amir Helzer et d'apprendre de leurs 2+ années d'expérience dans l'utilisation des déploiements par étapes avec WPML et Toolset, des plugins fonctionnant sur plus de 1 000 000 sites Web WordPress.
Voici ce qu'Amir a partagé à propos de la mise en œuvre de ses déploiements par étapes :
Lorsqu'un site Web installe l'un de nos plugins, nous tirons un nombre aléatoire entre 1 et 100 et le stockons dans la base de données du site pour nous en souvenir. Cette méthode divise essentiellement les sites Web en 100 bacs de manière aléatoire.
Lorsqu'une version est prête à être mise en ligne, elle ne devient disponible que progressivement pour un seul bac sélectionné. Chaque jour, nous augmentons l'exposition de la version à 5 % supplémentaires de sites Web dans la corbeille désignée. Et corrigez et corrigez les problèmes à venir au fur et à mesure.
Pour diversifier les environnements à l'aide de la version mise à jour et éviter d'avoir les mêmes "victimes" de la première version à plusieurs reprises, Amir a confirmé que chaque nouvelle version est d'abord destinée à un groupe d'utilisateurs différent.
Cette approche signifie également qu'un cycle de publication moyen prend environ un mois pour être disponible pour chaque utilisateur.
Cela prend du temps jusqu'à ce que les gens voient une nouvelle version disponible dans WP Admin et mettent à jour leur version. Et même après cela, cela peut prendre des jours avant qu'ils ne découvrent un problème.
Avec la taille de notre public, inévitablement, chaque version a des problèmes. Notre objectif principal est de nous assurer que nous évitons d'introduire de nouveaux problèmes, et si nous le faisons, nous avons un processus fiable pour les résoudre.
Le cycle de publication est en effet long, mais même si, dans le pire des cas, il y a un bug fou que nous avons manqué lors des tests, 95 % de nos utilisateurs ne sont même pas conscients de tout le drame, car ils ne sont pas exposés à la sortie jusqu'à ce que ce soit stable.
Amir a également souligné l'importance de la synchronisation avec toute l'équipe avant les versions, en particulier le support client et le développement. De cette façon, les membres de l'équipe peuvent se concentrer davantage sur les tickets déclenchés en raison de problèmes liés à la version en cours, dans le but de vérifier, confirmer et résoudre les problèmes valides et de publier les correctifs le plus rapidement possible.
Nous avons trois niveaux de support dans notre équipe. Le niveau 1 examinera le problème, validera qu'il s'agit en fait d'un problème lié à la sortie du plugin en le reproduisant. Lorsqu'un cas semble lié à la nouvelle version, il passe au niveau 2, qui débogue le problème pour valider qu'il est bien lié à la version et localise les parties pertinentes dans le code qui déclenche le problème. S'il est validé, le développeur responsable de ce code sera immédiatement averti pour prioriser un correctif.
OnTheGoSystems est une grande entreprise avec près de 100 employés, il est donc logique qu'ils aient perfectionné leur processus de déploiement par étapes. Mais, même en tant que développeur de produit unique avec un seul niveau de support (vous et vous-même), la perspicacité d'Amir peut nous apprendre qu'il est essentiel d'allouer des ressources dédiées aux versions. C'est une bonne pratique de donner la priorité aux tickets d'assistance qui "sentent" même être liés à votre nouvelle version et de réduire autant que possible l'exposition aux nouveaux problèmes.
Pourquoi n'y a-t-il (presque) aucun plugin ou thème prenant en charge les déploiements par étapes ?
En préparation de la rédaction de cet article, j'ai essayé de demander à la communauté de voir qui utilise les déploiements par étapes afin d'obtenir des commentaires sur leur expérience, ce qu'ils ont appris, etc.
Sans surprise, je n'ai trouvé que deux sociétés WordPress dans mon réseau qui ont mis en place des déploiements par étapes dans le cadre de leur cycle de publication. De nombreux développeurs ne connaissaient même pas le concept, et les autres ne l'utilisent pas car leur solution de distribution ne le supporte pas (ou ils ont peut-être pensé à le développer et n'ont pas le temps).
La plupart des développeurs de plugins et de thèmes qui ne vendent pas via Freemius vendent à partir de leur site Web via EDD ou WooCommerce, qui ne prennent pas en charge les déploiements par étapes. Ceux qui vendent via des marchés comme CodeCanyon et ThemeForest n'ont pas non plus de solution prête à l'emploi et n'en auront probablement jamais.
Même les développeurs qui connaissent le concept n'ont d'autre choix que de développer leur propre mécanisme pour prendre en charge les déploiements par étapes. Ce développement infrastructurel est généralement très difficile à prioriser au sein d'une entreprise de produits.
Abonnez-vous et obtenez une copie gratuite de notre
Livre d'affaires du plugin WordPress
Exactement comment créer une entreprise prospère de plugins WordPress dans l'économie des abonnements.
Partager avec un ami
Saisissez l'adresse e-mail de votre ami. Nous leur enverrons seulement ce livre par e-mail, l'honneur du scout.
Merci pour le partage
Génial - une copie de 'The WordPress Plugin Business Book' vient d'être envoyée à . Vous voulez nous aider à faire passer le mot encore plus ? Allez-y, partagez le livre avec vos amis et collègues.
Merci pour votre subscription!
- nous venons d'envoyer votre copie de 'The WordPress Plugin Business Book' à .
Vous avez une faute de frappe dans votre e-mail ? cliquez ici pour modifier l'adresse e-mail et envoyer à nouveau.
Comment les déploiements par étapes vous donnent-ils un avantage commercial ?
Étant donné que presque personne ne profite des déploiements par étapes pour le moment, si vous commencez à utiliser les déploiements par étapes et que vous les commercialisez correctement sur votre site Web pour faire savoir aux visiteurs que vous avez des cycles de publication responsables, cela vous donne définitivement un avantage concurrentiel et augmente la confiance dans votre produit. /marque!
Si vous analysez le marché du point de vue d'un développeur, vous remarquerez que de nombreux développeurs suivent de près leurs concurrents et fixent généralement leurs prix dans la fourchette de prix du marché dans leur secteur vertical, ce qui conduit à des produits WordPress concurrents offrant des fonctionnalités similaires dans la même gamme de prix.
Du point de vue de l'acheteur, cela signifie qu'il est souvent difficile de savoir quel produit acheter, car ils ont tous des caractéristiques et des prix comparables. Mais, lorsque vous évaluez plusieurs plugins qui coûtent le même prix et, plus ou moins, ont les mêmes fonctionnalités, ne seriez-vous pas enclin à opter pour le produit qui propose des déploiements par étapes sachant que ses versions de production devraient être plus stables que ses concurrents ?
Les déploiements par étapes augmentent la confiance dans votre produit et votre entreprise. C'est un avantage sur lequel vous pouvez capitaliser avant que les déploiements par étapes ne deviennent une pratique courante (ce que j'espère vraiment).
Freemius prend désormais en charge les déploiements par étapes pour les plugins et thèmes payants
Nous sommes ravis d'être les pionniers des déploiements par étapes dans l'écosystème premium des plugins et des thèmes WordPress. Nos partenaires commerciaux peuvent désormais publier des mises à jour en toute sécurité, en toute confiance et de manière fiable, avec un minimum de retour sur leurs utilisateurs ou leurs ressources de support/développement.
Nous savons à quel point les versions majeures peuvent être difficiles et éprouvantes pour les nerfs, d'autant plus qu'il existe toujours un risque potentiel d'avoir un impact négatif sur votre marque suite à une version "Clusterbug".
Avec les déploiements par étapes en place, il existe un filet de sécurité pour la durabilité et la défense de la marque de nos partenaires, et soulage le stress inutile associé aux versions à une large base d'utilisateurs.
Cela va de pair comme un avantage pour les clients de nos partenaires. Lorsque les utilisateurs achètent des produits vendus via Freemius, ils peuvent désormais être sûrs d'opter pour une solution optimisée par Staged Rollouts et ils peuvent s'attendre à des versions beaucoup plus stables des plugins et thèmes premium utilisant le mécanisme.
Si vous vendez avec Freemius, voici comment utiliser correctement notre mécanisme de déploiement par étapes.
Comment Freemius a-t-il mis en place des déploiements par étapes ?
Chaque site Web qui active une licence pour déverrouiller un plugin ou un thème premium obtient un enregistrement dans notre base de données. La première chose que nous avons faite est d'introduire une nouvelle propriété last_served_update_version pour stocker la dernière version du produit qui a été mise à disposition sur un site Web.
Ensuite, nous avons enrichi la table chargée de stocker les données de release avec deux nouvelles propriétés : limit , uniques .
Lorsqu'un développeur signale une version comme publiée, la boîte de dialogue suivante lui est proposée, lui permettant de définir le pourcentage (ou le nombre) de sites Web disposant d'une licence active sur lesquels il souhaite déployer la version payante :
S'ils définissent un déploiement de version limitée, le système comptera le nombre total de sites Web actifs avec une licence active, puis définira la nouvelle propriété de limit de la version en conséquence.
Enfin, nous avons mis à jour le point de terminaison de l'API appelé par les sites Web pour vérifier s'il existe une nouvelle version et introduit la logique suivante (en pseudo-code) :
latest_version = load latest version of product X
If (website is on latest_version)
return “no new version”
If (last_served_update_version of website same as latest_version)
return “no new version”
If (latest_version is limited)
If (latest_version is limited AND uniques >= limit)
return “no new version”
previous_version = load the previous version of product X
If (previous_version is limited too AND uniques <= previous_version.uniques)
If (website not using previous_version AND
last_served_update_version different from previous_version)
return “no new version”
else If (random({true, false}) )
return “no new version”
Set last_served_update_version of website to latest_version
Increment uniques by 1
return latest_version
Cet algorithme garantit que :
- L'exposition de la version est limitée en fonction du pourcentage défini du déploiement.
- Si la version précédente est toujours mise en scène, c'est-à-dire qu'elle n'a jamais été exposée à l'ensemble de la base d'installation, les sites Web qui ont reçu la version mise en scène précédente seront d'abord exposés à la dernière version mise en scène.
Contrairement à l'architecture Staged Rollouts de WPML qui garantit que chaque version ira dans un sous-ensemble différent de sa base d'installation à l'aide de bacs logiques, notre implémentation repose sur le caractère aléatoire. Ainsi, un site Web peut obtenir deux versions préliminaires au cours de deux cycles de publication consécutifs. Cependant, l'avantage de cette approche est que nous avons pu expédier des déploiements par étapes à tous les clients de nos partenaires sans avoir besoin de pousser une mise à jour du SDK, ce qui peut prendre plusieurs mois, voire des années, pour se propager à tous les clients.
Pourquoi les déploiements par étapes sont-ils essentiels pour l'avenir de WordPress ?
Lorsque j'ai demandé à Amir quel était leur déclencheur pour développer des déploiements par étapes pour les cycles de publication de WPML, voici ce qu'il m'a dit :
Il y a 3 ans, à WordCamp Europe, j'ai passé du temps à discuter avec des clients WPML pour recueillir toutes sortes de commentaires sur leur expérience globale. La frustration numéro 1 que j'ai trouvée était que nos clients avaient peur de mettre à jour le plugin car cela pouvait casser leur site de manière inattendue.
Amir Helzer,
Fondateur de OnTheGoSystems (WPML, Toolset)
Je suis tout à fait d'accord avec ça.
Notre politique interne chez Freemius en matière de mise à jour des plugins et des thèmes est… tout simplement pas ! À deux exceptions près : s'il existe un problème de sécurité connu ou une fonctionnalité disponible dans une version plus récente dont nous avons besoin pour notre site.
Notre politique de mises à jour a été "écrite par le sang" après plusieurs incidents de mises à jour qui ont mal tourné et ont causé des maux de tête inattendus et une perte de temps, interrompant notre fonctionnement et nos délais. Et oui, nous aurions pu éviter une partie du stress avec un environnement de mise en scène, mais cela ne nous aurait pas épargné du temps et des tracas si nous voulions toujours poursuivre la mise à jour vers la production.
WordPress a un peu évolué depuis lors, et nous avons maintenant une désactivation automatique en cas d'échec du plugin. Cependant, cela ne s'applique pas aux thèmes et la désactivation d'un plugin critique pour notre site Web reste un gros problème.
L'essentiel est que si, en tant que développeur de plugins et PDG d'une entreprise qui aide des milliers de développeurs de plugins et de thèmes à développer leurs activités, je suis préoccupé par la rupture de notre site chaque fois que nous mettons à jour des plugins ou des thèmes sur notre site, cela signifie certainement la plupart des utilisateurs n'ont aucune confiance dans la mise à jour des logiciels dans notre espace.
Le manque de déploiements par étapes nous retient, ainsi que l'ensemble de l'écosystème WP, et donne aux solutions concurrentes basées sur SaaS un avantage considérable. Les utilisateurs de WiX et Shopify n'ont pas du tout besoin de penser aux mises à jour ! Les mises à jour se produisent simplement pour eux en arrière-plan, et leur logiciel est toujours à jour, en termes de sécurité et de fonctionnalités.
L'absence de déploiements par étapes retient l'ensemble de l'écosystème WP et donne aux solutions basées sur SaaS un avantage considérable. Les utilisateurs de WiX et Shopify n'ont pas besoin de penser aux mises à jour logicielles - elles se produisent simplement en arrière-plan.Tweet
Si vous avez regardé State of the Word la semaine dernière, le co-fondateur de WordPress, Matt Mullenweg, comprend clairement l'importance d'un logiciel à jour. Voici la vision de Matt pour les mises à jour WP :
… vous permettant d'activer les mises à jour automatiques pour Core. C'est la première étape vers notre objectif permettant à votre WordPress de se maintenir essentiellement, lorsque vous pouvez le configurer et l'oublier, et il obtiendra des mises à jour automatiques, en arrière-plan et sans tracas de tous vos plugins, thèmes et noyau.Tweet
La seule façon dont je peux imaginer que WordPress devienne un "set and forget" est si les mises à jour logicielles peuvent être plus fiables et fiables, et cela ne peut se produire qu'avec des déploiements par étapes.
WordPress.org : Voici comment vous pouvez introduire des déploiements par étapes pour le référentiel de plugins et de thèmes
Semblable à notre implémentation, deux nouvelles méta-options doivent être ajoutées à chaque version de plugin et de thème dans la base de données WordPress.org : limit et uniques .
L'édition de l'option méta limit peut être exposée dans la vue avancée pour le propriétaire connecté (et peut-être pour d'autres committers) :
Un développeur aura un moyen de contrôler l'exposition de chaque version, ainsi que la possibilité de fixer une limite pour la prochaine version.
Étant donné que WordPress.org ne stocke pas de données structurées pour chaque site Web recevant des mises à jour de WordPress.org, au lieu de stocker la dernière version « vue » par un site Web dans la base de données WordPress.org, le stockage des données peut être délégué aux sites Web. . Cela signifie que le transitoire 'update_plugins' et les données envoyées à l'API WordPress.org lors de la vérification des mises à jour devront être enrichies avec un last_served_update_version .
Enfin, les points de terminaison de l'API de mises à jour de WordPress.org peuvent être enrichis avec la même logique que celle que nous avons utilisée pour la mise en œuvre des déploiements par étapes de Freemius. Juste au lieu de s'appuyer sur la last_served_update_version de la base de données wp.org, le mécanisme dépendra de la valeur envoyée par le site Web par core.
Facile, non ?
en train de recruter 
Ramenons la confiance des utilisateurs pour appuyer sur le bouton de mise à jour
Nous voulons tous voir WordPress réussir et devenir constamment plus grand et meilleur !
Avec autant de ressources dans Gutenberg, il est clair que la direction de WordPress reconnaît que nous devons rendre la plate-forme beaucoup plus accessible pour le Joe moyen non technique. Le fait est que tant que les mises à jour logicielles ne sont pas fiables, même avec Gutenberg et tous les incroyables constructeurs de pages dont nous disposons, une personne non technique s'enfuira vers Wix lors de sa première mise à jour cassée, et je ne pourrais pas blâmer leur.
J'appelle le fondateur d'EDD, Pippin Williamson, le PDG de WooCommerce, Paul Maiorana, et l'équipe de WordPress.org : nous avons l'opportunité de rendre l'écosystème de plugins et de thèmes beaucoup plus stable pour la grande communauté WordPress. Permettons aux utilisateurs de garder leur logiciel sécurisé et à jour avec moins de peur et de frustration. Bien que cela ne semble pas être une priorité à court terme, je suis sûr que nous en profiterons tous à long terme.