Pastoreo de gatos: lecciones aprendidas durante el desarrollo para el entorno de WordPress

Cuando se lanzó Elementor 3.0 hace más de un año, en 2020, lo vimos como un paso significativo hacia un editor más rápido y significativamente más poderoso. Si bien eso es cierto, esta versión también tuvo consecuencias importantes e inesperadas: provocó que un número significativo de sitios dejaran de funcionar y, francamente, perjudicó nuestra reputación. Después de este lanzamiento, necesitábamos encontrar una serie de correcciones para que estos sitios funcionaran nuevamente. Además, toda la experiencia nos mostró que necesitábamos revisar todo nuestro procedimiento de prueba y lanzamiento. Si bien es doloroso, este proceso está dando sus frutos hoy, como se refleja en la extraordinaria caída de problemas, especialmente los críticos, entre el lanzamiento de nuestras versiones v3.0 y v3.4:

Ahora que nos acercamos al primer aniversario de Elementor 3.0, es un buen momento para mirar hacia atrás y examinar los procedimientos que implementamos para garantizar que los problemas que acompañan a su lanzamiento no vuelvan a ocurrir. Para ser lo más transparente posible con nuestra comunidad, me gustaría examinar los antecedentes de los problemas relacionados con la versión 3.0, los pasos que tomamos durante el año pasado, cómo pudimos garantizar versiones estables y lo que depara el futuro. Pero primero, es importante comprender un poco de la historia de Elementor y los desafíos que enfrentamos al desarrollar un complemento complicado y sofisticado dentro del entorno de WordPress.

Elementor y el desafío de WordPress

En junio de 2016, cuando lanzamos la primera versión de Elementor, éramos solo unos "niños" a los que les gustaba desarrollar complementos y ayudar a las personas a crear sitios web. Este no fue nuestro primer producto, ya habíamos desarrollado algunos complementos que utilizaba la comunidad de WordPress. Sin embargo, mientras trabajábamos en Elementor, nos convencimos de que estábamos desarrollando algo especial. Resultó que teníamos razón: solo unos meses después de nuestro primer lanzamiento, decenas de miles de usuarios ya habían instalado Elementor y lo estaban usando para crear sitios web en todo el mundo.

Desde entonces, nuestra empresa ha crecido en todos los sentidos, con más desarrolladores, más usuarios y más funciones. Con este crecimiento surgió una serie de problemas nuevos, incluido un déficit tecnológico creciente a medida que nos enfocamos en problemas urgentes, dejando de lado problemas importantes pero más mundanos.

Lidiar con estos problemas se hizo aún más difícil por el desafío general planteado por la naturaleza del entorno de WordPress.

Como plataforma abierta, WordPress ofrece una serie de grandes ventajas para los desarrolladores. Hay algunos obstáculos que monitorean y ralentizan los lanzamientos. Los conceptos se imaginan, desarrollan y agregan al repositorio. Los usuarios prueban, prueban y juzgan estos productos, y el mercado decide cuáles prosperarán y cuáles fallarán. Sin embargo, esta velocidad y simplicidad tienen un precio.

Hay poca uniformidad en el entorno de WordPress y no hay un flujo de trabajo ordenado. Los creadores web son libres de definir el entorno de sus sitios mientras usan una amplia gama de complementos, temas, etc. Esto significa que los sitios de WordPress contienen innumerables combinaciones de complementos, temas y configuraciones de servidor.

Además, la simplicidad del proceso de lanzamiento y la falta de herramientas de implementación sólidas significa que los desarrolladores de WordPress no pueden aprovechar los conceptos de lanzamiento modernos como CI/CD, Canary Deployment y Feature Flags.

Si bien la apertura es parte de la belleza de WordPress, la multitud inherente de configuraciones de sitios y servidores presenta a los desarrolladores un verdadero desafío cuando se trata de tener en cuenta los conflictos de complementos y los problemas específicos del servidor.

En nuestro caso, como Elementor se usaba para más y más sitios web, la necesidad de admitir todas estas combinaciones diferentes estaba ralentizando nuestro programa de lanzamiento e incluso nos hizo dudar en desarrollar nuevas funciones. No hace falta decir que esta situación era inaceptable y necesitábamos cambiar las cosas.

Desarrollo de nuevas funciones sin romper las antiguas

Todos los factores anteriores nos dejaron con el dilema de cómo podríamos continuar desarrollándonos y mejorando sin afectar negativamente el trabajo de aquellos que ya confiaban en Elementor.

Comenzamos implementando algunos pequeños cambios en nuestro proceso de lanzamiento. En Elementor 1.5, comenzamos a ofrecer acceso a los desarrolladores a las versiones Beta. Hicimos esto a través de Github y otras comunidades, lo que nos permitió recibir comentarios antes de un lanzamiento, indicando cómo interactuaba esta versión con una amplia variedad de combinaciones de complementos, temas y entornos, y alertándonos sobre cualquier incompatibilidad desde el principio. Este enfoque funcionó bien durante un tiempo, pero a medida que Elementor crecía aún más, descubrimos que esto no era suficiente.

En ese momento, habíamos cruzado el umbral de cinco millones de instalaciones. Si bien fue un logro increíble, también significó que ahora éramos responsables de que todos estos sitios web funcionaran sin problemas.

Las cosas finalmente llegaron a un punto crítico con el lanzamiento de Elementor 3.0. En esta versión, decidimos eliminar algunas funciones antiguas aparentemente obsoletas, eliminando elementos DOM para aumentar las velocidades de carga. Esto fue, al menos parcialmente, en respuesta a quejas justificadas de que estábamos sobrecargando innecesariamente el sistema.

Desafortunadamente, este cambio provocó que varios sitios, que dependían del código que habíamos eliminado, fallaran durante la actualización. A pesar de nuestros esfuerzos por involucrar a desarrolladores externos en el proceso, estos errores permanecieron sin descubrir y tuvimos que actuar rápidamente para corregir la situación. Al final, pudimos hacerlo al hacer que partes de la actualización fueran opcionales, pero no antes de que algunos miembros de nuestra comunidad vieran afectada su confianza en la estabilidad de nuestro complemento.

Esta experiencia nos obligó a analizar detenidamente nuestro proceso de desarrollo, con miras a realizar una serie de cambios importantes. Nuestros procesos simplemente no eran adecuados para una empresa de nuestro tamaño y base instalada. El primer movimiento, y quizás el más obvio, fue aumentar el tamaño y el alcance de nuestro equipo de control de calidad, pero esto aún nos dejó lidiando con varios problemas pendientes:

• Comprobación de la compatibilidad de una versión con innumerables configuraciones de sitios
• Garantía de compatibilidad con versiones anteriores de más de cinco millones de sitios existentes
• Comprobación de la compatibilidad de cientos de extensiones de Elementor de terceros

Para lidiar con todos estos problemas, necesitábamos traer métodos de desarrollo de software más actualizados al mundo de WordPress.

El circuito de retroalimentación

Uno de los grandes problemas que enfrenta el desarrollo, en general, es que los usuarios solo experimentan actualizaciones una vez que se han lanzado. Eso significa que una característica ya ha sido diseñada, desarrollada y lanzada cuando recibimos comentarios de los usuarios. En nuestro caso, al tratar con cientos de cientos de extensiones y complementos de terceros, el problema de este ciclo de retroalimentación es aún más importante.

Al buscar formas de acortar este ciclo de retroalimentación, observamos cómo los desarrolladores de navegadores manejan problemas similares a los nuestros; también deben garantizar la compatibilidad con innumerables páginas web, aplicaciones, extensiones y más de terceros.

Por ejemplo, examinamos el sistema desarrollado por Google para su navegador Chrome. En cualquier momento, los desarrolladores tienen acceso a tres versiones del navegador: una versión beta, una versión para desarrolladores y una versión nocturna. Esto significa que los desarrolladores pueden echar un vistazo temprano a las nuevas funciones de Chrome y pueden comenzar a enviar comentarios a Google mucho antes del lanzamiento oficial de la versión.

Al aplicar estas lecciones a nuestro complemento, Elementor comenzó a lanzar su propia edición para desarrolladores: Elementor Beta (Edición para desarrolladores), disponible en el repositorio de WordPress y dirigida a los desarrolladores que están interesados ​​en ver nuestras nuevas funciones "recién salidas de prensa", por así decirlo.

Para nosotros, por supuesto, nos beneficiamos al recibir alertas tempranas de problemas de compatibilidad. La edición para desarrolladores no solo permite a los usuarios acceder a todas estas nuevas funciones, sino que incluso hay un enlace directo a Github para informar errores. Esto significa que podemos implementar continuamente nuevas funciones y recibir comentarios sobre ellas, sin poner en peligro los sitios web existentes. Para los desarrolladores, esto les permite prepararse para los próximos lanzamientos oficiales con mucha anticipación, lo que ayuda a prevenir sus propios problemas de compatibilidad y también les brinda la oportunidad de proporcionar comentarios técnicos y sobre el producto mientras se trabaja en la función.

Cabe señalar que los lanzamientos de la edición para desarrolladores se ejecutan en paralelo al proceso normal (alfa, beta, RC y producción) que se utiliza para desarrollar los lanzamientos de Elementor. Cuando desarrollamos una nueva característica, tan pronto como sea lo suficientemente estable para usarla, pero mientras todavía está en alfa, la agregamos a la edición para desarrolladores. De esta manera, nuestros desarrolladores pueden darnos su opinión, incluso antes de que la función llegue a la versión beta. También significa que la edición para desarrolladores incluye características que no han llegado a la etapa beta.

Esencialmente, la etapa beta está reservada para un proceso de depuración deliberado, mientras que la edición para desarrolladores se actualiza con mayor frecuencia, incorporando características en sus primeras etapas.

Desde su presentación, la edición para desarrolladores ha demostrado ser un gran éxito, acumulando más de 40 mil instalaciones en menos de un año.

Presentamos funciones "experimentales"

A lo largo de los años, otro concepto que los desarrolladores han adoptado son las banderas de funciones, que prevalecen especialmente en el mundo de SaaS. La idea general es que estos indicadores de funciones permitan a los desarrolladores probar nuevas funciones al activarlas y desactivarlas para que diferentes segmentos de usuarios las prueben y vean cómo funcionan.

Como se mencionó anteriormente, muchos de los problemas derivados del lanzamiento de 3.0 se debieron a las nuevas características que eliminaron el código anterior. Para evitar este tipo de problemas, decidimos adoptar un enfoque similar al de las banderas de funciones.

Comenzando con Elementor 3.1, comenzamos a lanzar nuevas funciones con más cuidado, marcándolas como "experimentales". Esto incluye un sistema de introducción de nuevas características en etapas. En este sistema, una función recientemente desarrollada se marcará como "Alfa". Esto significa que está desactivado, de forma predeterminada, en todos los sitios. A medida que demuestra ser más estable, se convierte en una "Beta", lo que significa que ahora está activado, de forma predeterminada, para sitios nuevos y desactivado para sitios existentes. Una vez que estamos seguros de que es estable, se activa de forma predeterminada para todos los sitios. Incluso entonces, habrá una opción para que los usuarios desactiven la función, por un tiempo limitado.

Este sistema nos permite continuar desarrollando Elementor, agregando tanto su conjunto de funciones como su velocidad, al tiempo que permite a los creadores optar por participar o no en estas nuevas actualizaciones según las necesidades de su sitio. Esto también ayuda a los creadores a actualizar sus sitios al permitirles adoptar nuevas funciones con más cuidado.

Etiquetas de compatibilidad

El crecimiento de la comunidad de desarrolladores muy activa de Elementor ha sido un gran motivo de orgullo, pero también ha planteado sus propios desafíos. Los desarrolladores externos han creado cientos de extensiones, temas, kits y widgets, todos basados ​​en nuestra tecnología existente.

Con el fin de apoyar a los desarrolladores de estos complementos de terceros, usamos nuestro blog de desarrolladores y nuestra lista de correo para informarles con anticipación sobre los cambios que estábamos realizando en la API, así como sobre las obsolescencias. Sin embargo, como se mencionó anteriormente, descubrimos que esto no era suficiente. Muchos de los problemas que experimentamos con los nuevos lanzamientos tenían problemas de compatibilidad debido a estos complementos de terceros. Nuestro complemento se consideró inestable, no por nuestra tecnología, sino por estas incompatibilidades de terceros.

Nuevamente, buscamos inspiración en lo que otros estaban haciendo. En este caso, WooCommerce y su enfoque para trabajar con desarrolladores externos. A partir de nuestro lanzamiento 3.1, comenzamos un sistema en el que los desarrolladores externos certifican que sus extensiones son compatibles con la nueva versión (Más información). Luego, cuando a los usuarios se les da la opción de actualizar Elementor, se les presenta una lista de extensiones de terceros que están usando y si han sido certificadas o no como compatibles con la nueva versión de Elementor. De esta manera, los usuarios pueden tomar una decisión informada sobre la actualización.

Hacia un futuro aún mejor

Al describir estos desafíos y los cambios que hemos implementado, espero haberles dado una idea de lo que es desarrollar un producto para uso mundial, en un entorno de código abierto y en constante cambio. Como parte de esta cultura de código abierto, es fundamental que seamos transparentes con nuestra comunidad de usuarios y desarrolladores, más aún a medida que la empresa crece y se vuelve más difícil mantener un "toque personal". No solo porque el dolor de nuestros usuarios es nuestro dolor, sino porque es la mejor manera de que Elementor siga siendo una herramienta estable, abierta a la mayor variedad posible de usuarios.

Creemos firmemente que los cambios que hemos implementado contribuyeron y seguirán contribuyendo al crecimiento y éxito de Elementor. Sin embargo, también somos conscientes de que aún queda trabajo por hacer y que la comunicación entre Elementor y la comunidad de Elementor debe permanecer abierta e incluso mejorar. Por ejemplo, estamos actualizando nuestro sitio de recursos para desarrolladores, brindando documentación fácil de usar para ayudar a los desarrolladores a personalizar y desarrollar Elementor.
Pero quizás el paso más importante que hemos dado para mejorar la comunicación es establecer Elementor Community Hub. Aquí, los creadores web de todo el mundo pueden reunirse para intercambiar ideas entre ellos y con nosotros, colaborando juntos para hacer de Elementor lo mejor posible. Después de todo, como sugiere el viejo refrán, pastorear gatos puede ser casi imposible, pero cuando trabajan juntos, se llama Orgullo.