Herding Cats - Leçons apprises lors du développement pour l'environnement WordPress

Lorsque Elementor 3.0 est sorti il ​​y a plus d'un an, en 2020, nous y avons vu une étape importante vers un éditeur plus rapide et nettement plus puissant. Bien que cela soit vrai, cette version a également eu des conséquences importantes et inattendues - elle a provoqué l'arrêt d'un nombre important de sites et, très franchement, a nui à notre réputation. Suite à cette version, nous avons dû proposer une série de correctifs afin de faire fonctionner à nouveau ces sites. De plus, toute l'expérience nous a montré que nous devions revoir l'ensemble de notre procédure de test et de publication. Bien que pénible, ce processus porte aujourd'hui ses fruits comme en témoigne l'extraordinaire baisse des problèmes, notamment critiques, entre la sortie de nos versions v3.0 et v3.4 :

Maintenant, alors que nous approchons du premier anniversaire d'Elementor 3.0, c'est le bon moment pour regarder en arrière et examiner les procédures que nous avons mises en place pour nous assurer que les problèmes qui accompagnent sa sortie ne se reproduisent plus. Afin d'être aussi transparent que possible avec notre communauté, j'aimerais examiner le contexte des problèmes entourant la version 3.0, les étapes que nous avons franchies au cours de l'année écoulée, comment nous avons pu assurer des versions stables et ce que l'avenir nous réserve. Mais d'abord, il est important de comprendre un peu l'histoire d'Elementor et les défis auxquels nous sommes confrontés pour développer un plugin compliqué et sophistiqué dans l'environnement WordPress.

Elementor et le défi WordPress

En juin 2016, lorsque nous avons sorti la première version d'Elementor, nous n'étions que quelques "enfants", qui aimaient développer des plugins et aider les gens à créer des sites Web. Ce n'était pas notre premier produit, nous avions déjà développé quelques plugins utilisés par la communauté WordPress. Cependant, en travaillant sur Elementor, nous sommes devenus convaincus que nous développions quelque chose de spécial. En fin de compte, nous avions raison - quelques mois seulement après notre première version, des dizaines de milliers d'utilisateurs avaient déjà installé Elementor et l'utilisaient pour créer des sites Web dans le monde entier.

Depuis lors, notre entreprise s'est développée dans tous les sens, avec plus de développeurs, plus d'utilisateurs et plus de fonctionnalités. Cette croissance s'est accompagnée d'une série de nouveaux problèmes, notamment un déficit technologique croissant alors que nous nous concentrions sur les problèmes urgents, mettant de côté les problèmes importants, mais plus banals.

La gestion de ces problèmes a été rendue encore plus difficile par le défi global posé par la nature de l'environnement WordPress.

En tant que plate-forme ouverte, WordPress offre de nombreux avantages aux développeurs. Il existe quelques obstacles qui surveillent et ralentissent les versions. Les concepts sont imaginés, développés et ajoutés au référentiel. Les utilisateurs essaient, testent et jugent ces produits, le marché décidant lesquels prospéreront et lesquels échoueront. Cependant, cette rapidité et cette simplicité ont un prix.

Il y a peu d'uniformité dans l'environnement WordPress et aucun flux de travail ordonné. Les créateurs Web sont libres de définir l'environnement de leurs sites tout en utilisant une vaste gamme de plugins, de thèmes, etc. Cela signifie que les sites WordPress contiennent d'innombrables combinaisons de plugins, de thèmes et de configurations de serveur.

De plus, la simplicité du processus de publication et le manque d'outils de déploiement robustes signifient que les développeurs WordPress ne sont pas en mesure de tirer parti des concepts de publication modernes tels que CI/CD, Canary Deployment et Feature Flags.

Bien que l'ouverture fasse partie de la beauté de WordPress, la multitude inhérente de configurations de sites et de serveurs présente aux développeurs un véritable défi lorsqu'il s'agit de prendre en compte les conflits de plugins et les problèmes de serveur spécifiques.

Dans notre cas, comme Elementor était utilisé pour de plus en plus de sites Web, la nécessité de prendre en charge toutes ces différentes combinaisons ralentissait notre calendrier de publication et nous faisait même hésiter à développer de nouvelles fonctionnalités. Inutile de dire que cette situation était inacceptable et qu'il fallait faire bouger les choses.

Développer de nouvelles fonctionnalités sans casser l'ancienne

Tous les facteurs ci-dessus nous ont laissé le dilemme de savoir comment continuer à nous développer et à nous améliorer sans impacter négativement le travail de ceux qui comptaient déjà sur Elementor ?

Nous avons commencé par implémenter quelques petits changements dans notre processus de publication. Dans Elementor 1.5, nous avons commencé à offrir aux développeurs un accès aux versions bêta. Nous l'avons fait via Github et d'autres communautés, ce qui nous a permis de recevoir des commentaires avant une publication, indiquant comment cette version interagissait avec une grande variété de combinaisons plugin/thème/environnement et nous alertant très tôt de toute incompatibilité. Cette approche a bien fonctionné pendant un certain temps, mais au fur et à mesure de la croissance d'Elementor, nous avons découvert que cela ne suffisait pas.

À cette époque, nous avions franchi le seuil des cinq millions d'installations. Bien qu'il s'agisse d'une réalisation incroyable, cela signifiait également que nous étions désormais responsables du bon fonctionnement de tous ces sites Web.

Les choses ont finalement atteint leur paroxysme avec la sortie d'Elementor 3.0. Dans cette version, nous avons décidé de supprimer certaines fonctions anciennes, apparemment obsolètes, en supprimant des éléments DOM pour augmenter les vitesses de chargement. C'était, au moins en partie, en réponse à des plaintes justifiées selon lesquelles nous alourdissions inutilement le système.

Malheureusement, ce changement a provoqué la panne d'un certain nombre de sites, qui s'appuyaient sur du code que nous avions supprimé, lors de la mise à niveau. Malgré nos efforts pour faire participer des développeurs tiers au processus, ces bogues n'avaient pas été découverts et nous avons dû agir rapidement pour corriger la situation. En fin de compte, nous avons pu le faire en rendant certaines parties de la mise à niveau facultatives, mais pas avant que certains membres de notre communauté aient eu leur confiance dans la stabilité de notre plugin, ébranlée.

Cette expérience nous a obligés à examiner longuement et attentivement notre processus de développement, en vue d'apporter un certain nombre de changements majeurs. Nos processus n'étaient tout simplement pas adaptés à une entreprise de notre taille et de notre base d'installation. La première décision, et peut-être la plus évidente, a été d'augmenter la taille et la portée de notre équipe d'assurance qualité, mais cela nous a quand même laissé aux prises avec un certain nombre de problèmes en suspens :

• Vérification de la compatibilité d'une version avec d'innombrables configurations de site
• Assurer la rétrocompatibilité avec plus de cinq millions de sites existants
• Vérification de la compatibilité de centaines d'extensions Elementor tierces

Pour faire face à tous ces problèmes, nous devions apporter des méthodes de développement de logiciels plus à jour dans le monde WordPress.

La boucle de rétroaction

L'un des gros problèmes auxquels est confronté le développement, en général, est que les utilisateurs ne voient les mises à jour qu'une fois qu'elles ont été publiées. Cela signifie qu'une fonctionnalité a déjà été conçue, développée et publiée au moment où nous recevons les commentaires des utilisateurs. Dans notre cas, face à des centaines de centaines d'extensions et de plugins tiers, le problème de cette boucle de rétroaction est encore plus important.

En cherchant des moyens de raccourcir cette boucle de rétroaction, nous avons examiné comment les développeurs de navigateurs traitent des problèmes assez similaires aux nôtres - ils doivent également assurer la compatibilité avec d'innombrables pages Web, applications, extensions, etc.

Par exemple, nous avons examiné le système développé par Google pour son navigateur Chrome. À tout moment, les développeurs ont accès à trois versions du navigateur : une version bêta, une version de développement et une version nocturne. Cela signifie que les développeurs ont un aperçu précoce des nouvelles fonctionnalités de Chrome et peuvent commencer à faire part de leurs commentaires à Google bien avant la sortie officielle de la version.

En appliquant ces leçons à notre plugin, Elementor a commencé à publier sa propre édition développeur - Elementor Beta (Developer Edition), disponible à partir du référentiel WordPress et destinée aux développeurs qui souhaitent découvrir nos nouvelles fonctionnalités "tout juste sorties des presses" pour ainsi dire.

Pour nous, bien sûr, nous bénéficions en recevant des avertissements précoces de problèmes de compatibilité. L'édition développeur permet non seulement aux utilisateurs d'accéder à toutes ces nouvelles fonctionnalités, mais il existe même un lien direct vers Github pour signaler les bogues. Cela signifie que nous pouvons continuellement déployer de nouvelles fonctionnalités et recevoir des commentaires à leur sujet, sans mettre en danger les sites Web existants. Pour les développeurs, cela leur permet de se préparer bien à l'avance aux prochaines versions officielles, en aidant à prévenir leurs propres problèmes de compatibilité et en leur donnant également la possibilité de fournir des commentaires sur les produits et techniques pendant que la fonctionnalité est encore en cours d'élaboration.

Il convient de noter que les versions de l'édition développeur s'exécutent en parallèle de la normale - alpha, bêta, RC et production - un processus utilisé pour développer les versions d'Elementor. Lorsque nous développons une nouvelle fonctionnalité, dès qu'elle est suffisamment stable pour être utilisée, mais tant qu'elle est encore en alpha, nous l'ajoutons à l'édition développeur. De cette façon, nos développeurs peuvent nous faire part de leurs commentaires, avant même que la fonctionnalité n'atteigne la version bêta. Cela signifie également que l'édition développeur inclut des fonctionnalités qui n'ont pas atteint le stade bêta.

Essentiellement, la phase bêta est réservée à un processus de débogage délibéré, tandis que l'édition développeur est mise à jour plus fréquemment, incorporant des fonctionnalités à leurs tout premiers stades.

Depuis son introduction, l'édition pour développeurs s'est avérée un grand succès, recueillant plus de 40 000 installations en moins d'un an.

Présentation des fonctionnalités "expérimentales"

Au fil des ans, un autre concept que les développeurs ont adopté est celui des drapeaux de fonctionnalités, qui sont particulièrement répandus dans le monde du SaaS. L'idée générale est que ces indicateurs de fonctionnalité permettent aux développeurs de tester de nouvelles fonctionnalités en les activant et en les désactivant pour différents segments d'utilisateurs afin de les tester et de voir comment ils fonctionnent.

Comme mentionné ci-dessus, de nombreux problèmes liés à la version 3.0 étaient dus à de nouvelles fonctionnalités éliminant l'ancien code. Afin d'éviter ce genre de problèmes, nous avons décidé d'adopter une approche similaire à celle des feature flags.

À partir d'Elementor 3.1, nous avons commencé à publier de nouvelles fonctionnalités avec plus de soin, en les signalant comme "expérimentales". Cela inclut un système d'introduction de nouvelles fonctionnalités par étapes. Dans ce système, une fonctionnalité nouvellement développée sera signalée comme "Alpha". Cela signifie qu'il est désactivé, par défaut, sur tous les sites. Au fur et à mesure qu'il se révèle plus stable, il devient une "bêta", ce qui signifie qu'il est désormais activé, par défaut, pour les nouveaux sites et désactivé pour les sites existants. Une fois que nous sommes sûrs qu'il est stable, il est activé, par défaut, pour tous les sites. Même dans ce cas, les utilisateurs auront la possibilité de désactiver la fonctionnalité, pour une durée limitée.

Ce système nous permet de continuer à développer Elementor, en ajoutant à la fois son ensemble de fonctionnalités et sa vitesse, tout en permettant aux créateurs d'activer ou de désactiver ces nouvelles mises à niveau en fonction des besoins de leur site. Cela aide également les créateurs à mettre à jour leurs sites en leur permettant d'adopter de nouvelles fonctionnalités avec plus de soin.

Balises de compatibilité

La croissance de la communauté de développeurs très active d'Elementor a été une grande source de fierté, mais a également posé ses propres défis. Des développeurs tiers ont créé des centaines d'extensions, de thèmes, de kits et de widgets, tous basés sur notre technologie existante.

Afin de soutenir les développeurs de ces modules complémentaires tiers, nous avons utilisé le blog de nos développeurs et notre liste de diffusion pour les informer rapidement des modifications que nous apportions à l'API ainsi que des obsolescences. Cependant, comme mentionné ci-dessus, nous avons découvert que cela ne suffisait pas. La plupart des problèmes que nous rencontrions avec les nouvelles versions rencontraient des problèmes de compatibilité en raison de ces modules complémentaires tiers. Notre plugin était considéré comme instable, non pas à cause de notre technologie, mais à cause de ces incompatibilités tierces.

Encore une fois, nous avons regardé ce que les autres faisaient pour nous inspirer. Dans ce cas, WooCommerce et leur approche de travail avec des développeurs tiers. À partir de notre version 3.1, nous avons lancé un système dans lequel les développeurs tiers certifient que leurs extensions sont compatibles avec la nouvelle version (En savoir plus). Ensuite, lorsque les utilisateurs ont la possibilité de mettre à niveau Elementor, une liste des extensions tierces qu'ils utilisent leur est présentée et si elles ont été certifiées compatibles ou non avec la nouvelle version d'Elementor. De cette façon, les utilisateurs peuvent prendre une décision éclairée sur la mise à niveau.

Vers un avenir encore meilleur

En décrivant ces défis et les changements que nous avons mis en œuvre, j'espère vous avoir donné un aperçu de ce que c'est que de développer un produit pour une utilisation mondiale, dans un environnement open source et en constante évolution. Dans le cadre de cette culture open source, il est essentiel que nous soyons transparents avec notre communauté d'utilisateurs et de développeurs, d'autant plus que l'entreprise grandit et qu'il devient plus difficile de maintenir une « touche personnelle ». Non seulement parce que la douleur de nos utilisateurs est notre douleur, mais parce que c'est le meilleur moyen pour Elementor de rester un outil stable, ouvert au plus large éventail d'utilisateurs possible.

Nous croyons fermement que les changements que nous avons mis en œuvre ont contribué et continueront de contribuer à la croissance et au succès d'Elementor. Cependant, nous sommes également conscients qu'il reste encore du travail à faire et que la communication entre Elementor et la communauté Elementor doit rester ouverte et même améliorée. Par exemple, nous mettons à jour notre site de ressources pour les développeurs, en fournissant une documentation facile à utiliser pour aider les développeurs à personnaliser et à développer Elementor.
Mais peut-être que l'étape la plus importante que nous ayons franchie pour améliorer la communication est la création du hub communautaire Elementor. Ici, les créateurs Web du monde entier peuvent se réunir pour échanger des idées entre eux et avec nous - en collaborant ensemble pour faire d'Elementor le meilleur possible. Après tout, comme le dit le vieil adage, élever des chats est peut-être presque impossible, mais quand ils travaillent ensemble, cela s'appelle Pride.