Lanzamientos por etapas para desarrolladores de complementos y temas de WordPress: evitar un "lanzamiento de Clusterbug"
Publicado: 2020-12-23¿Recuerdas la última vez que lanzaste una nueva versión de tu complemento o tema de WordPress para descubrir rápidamente que agregaste por error un nuevo error importante que se deslizó a través de las grietas de la secuencia de prueba?
Yoast SEO 3.0 rompió muchos sitios web en 2015. Elementor 3.0 hizo lo mismo este año. Y esos son solo dos ejemplos de empresas fantásticas en nuestro espacio con más de 100 empleados y personal de control de calidad dedicado (y no, no está relacionado con la versión 3.0, pero tal vez sea una señal para omitir esa versión en su software; )).
Ya sea que sea un programador autodidacta o un ingeniero de software, un desarrollador independiente o parte de una gran tienda de complementos/temas, todos tenemos que lidiar con errores. Es una parte inevitable del desarrollo de software.
Independientemente de las sofisticadas automatizaciones de CI/CD/pruebas que implemente, nunca podrá probarlo todo. La cantidad de configuraciones de servidor (PHP, MySql, caché, servidor web), versiones de WP, combinaciones de complementos y temas… es interminable.
Y es contraintuitivo. Cuanto más populares y estables se vuelvan sus productos, mayores serán las posibilidades de un temido lanzamiento de "Clusterbug", que agotará su apoyo, puede afectar significativamente la confianza y lealtad de sus clientes y potencialmente dañar la reputación general de la marca.
Si bien no puede evitar errores, puede, y definitivamente debe, mitigar el riesgo tanto como pueda.
Si tiene un teléfono inteligente, probablemente haya notado que algunos de sus amigos reciben actualizaciones de Android/iOS días, semanas, a veces incluso meses antes de que usted las reciba. Eso no es una coincidencia, y no, no es nada personal contra ti. Es un proceso de implementación progresivo intencional llamado Implementaciones por etapas que ayuda a empresas como Apple a enviar importantes actualizaciones de software a más de mil millones de dispositivos.
¡Sí, mil millones!
¿Puedes siquiera comprender la cantidad de responsabilidad que un líder de versión en Apple tendría sobre sus hombros si tuvieran que enviar una actualización en vivo a 1.500 millones de dispositivos móviles simultáneamente? No puedo. Apuesto a que ningún hombre en su sano juicio aceptaría asumir tal responsabilidad.
Entonces, ¿cómo funciona el mecanismo de lanzamientos por etapas? ¿Cómo puedes implementarlo? ¿Y a qué espera WordPress.org? Estos son los temas que voy a cubrir a continuación.
¿Qué son los lanzamientos por etapas para los complementos y temas de WordPress?
Los lanzamientos por etapas le permiten especificar el número (o porcentaje) de sitios web en los que desea implementar una nueva versión. Un mecanismo de lanzamientos por etapas le permite comenzar su ciclo de lanzamiento con una exposición limitada y luego aumentarla gradualmente mientras supervisa el soporte y los comentarios, lo que genera confianza en su lanzamiento para usted y sus usuarios.
¿Cuáles son los beneficios de los lanzamientos por etapas?
En lugar de arriesgar toda su base de instalación con el lanzamiento de posibles errores, conflictos con complementos/temas de terceros o incluso problemas de UI/UX, puede lanzar versiones progresivamente, minimizando la cantidad de personas y sitios web que estarán expuestos a problemas inesperados. Una vez que solucione todos los problemas y errores descubiertos durante el proceso de implementación, la gran mayoría de sus usuarios estarán expuestos a una versión "madura" y mucho más estable.
Utilizamos actualizaciones continuas para garantizar la calidad de nuestros nuevos lanzamientos. Si hay un problema con una nueva versión, podemos identificarlo rápidamente y solo un pequeño subconjunto de usuarios se habría visto afectado.
John Turner, Fundador de SeedProd
El uso de lanzamientos por etapas es LA mejor práctica para lanzar software de manera responsable, un proceso que siguen muchas empresas (sin importar el tamaño) fuera de la burbuja de WP.
Existe una gran oportunidad para que la comunidad de WordPress aproveche los lanzamientos por etapas, a los que me referiré en un momento.
¿Los programas beta son similares a los lanzamientos por etapas?
Configurar un programa Beta para su producto de WordPress es un gran comienzo, pero está lejos de ser tan efectivo como los lanzamientos por etapas, y tiene un propósito y una dinámica fundamentalmente diferentes.
A menos que su complemento o tema sea extremadamente popular y tenga una gran comunidad, es bastante difícil reclutar un grupo beta estadísticamente suficiente, ya que solo una pequeña fracción de los usuarios estará interesada en unirse. Incluso si se destaca en la contratación de un grupo decente de probadores beta, debe confiar en su disponibilidad y buena voluntad para probar el producto, y luego esperar que hagan un esfuerzo adicional para informar los problemas que encuentren.
¿Cuántas personas crees que verán a través de todo este proceso? No muchos.
La prueba beta es un proceso de preproducción en el que sus esfuerzos de soporte están completamente controlados y los evaluadores esperan tener problemas con las versiones beta. Por lo tanto, las expectativas de calidad de los evaluadores no representan el sentimiento general de su base de usuarios.
Además, un programa Beta responsable advertirá a sus evaluadores que eviten usar versiones beta en entornos de producción, por lo que las pruebas beta no simulan realmente sitios web de producción en vivo.
¿Cómo administrar un lanzamiento de lanzamiento por etapas para su complemento o tema de WordPress?
Como parte de mi investigación sobre Staged Rollouts, tuve la oportunidad de conocer a Amir Helzer y aprender de sus más de 2 años de experiencia en el uso de Staged Rollouts con WPML y Toolset, complementos que se ejecutan en más de 1 000 000 de sitios web de WordPress.
Esto es lo que Amir compartió sobre su implementación de lanzamientos por etapas:
Cuando un sitio web instala cualquiera de nuestros complementos, extraemos un número aleatorio entre 1 y 100 y lo almacenamos en la base de datos del sitio para recordarlo. Este método esencialmente divide los sitios web en 100 contenedores de forma aleatoria.
Cuando una versión está lista para publicarse, solo estará disponible de forma incremental para un solo contenedor seleccionado. Todos los días aumentamos la exposición del lanzamiento a un 5% adicional de sitios web en el contenedor designado. Y solucione y parchee los problemas futuros a medida que avanzamos.
Para diversificar los entornos usando la versión actualizada y evitar tener las mismas "víctimas" de lanzamiento anticipado repetidamente, Amir confirmó que cada nuevo lanzamiento va primero a un grupo diferente de usuarios.
Este enfoque también significa que un ciclo de lanzamiento promedio tarda aproximadamente un mes en estar disponible para cada usuario.
Toma tiempo hasta que las personas vean una nueva versión disponible en WP Admin y actualicen su versión. E incluso después de que lo hacen, pueden pasar días hasta que descubren un problema.
Con el tamaño de nuestra audiencia, inevitablemente, cada lanzamiento tiene algunos problemas. Nuestro objetivo principal es asegurarnos de evitar la introducción de nuevos problemas y, si lo hacemos, tenemos un proceso confiable para resolverlos.
El ciclo de lanzamiento es realmente largo, pero incluso si, en el peor de los casos, hay algún error loco que no detectamos en las pruebas, el 95 % de nuestros usuarios ni siquiera son conscientes de todo el drama, ya que no están expuestos al lanzamiento. hasta que sea estable.
Amir también enfatizó la importancia de sincronizar con todo el equipo antes de los lanzamientos, especialmente con el soporte al cliente y el desarrollo. De esta manera, los miembros del equipo pueden concentrarse más en los tickets activados debido a problemas relacionados con el lanzamiento en curso, con el objetivo de verificar, confirmar y solucionar problemas válidos y lanzar parches lo más rápido posible.
Tenemos tres niveles de soporte en nuestro equipo. El nivel 1 analizará el problema, validará que en realidad sea un problema relacionado con el lanzamiento del complemento al reproducirlo. Cuando un caso parece estar relacionado con la nueva versión, pasa al nivel 2, que depurará el problema para validar que realmente está relacionado con la versión y ubicar las partes relevantes en el código que desencadena el problema. Si se valida, el desarrollador responsable de ese código recibirá una notificación de inmediato para priorizar una solución.
OnTheGoSystems es una gran empresa con casi 100 empleados, por lo que tiene sentido que hayan perfeccionado su proceso de implementación por etapas. Pero, incluso como desarrollador de un solo producto con un nivel de soporte (usted y usted mismo), la perspectiva de Amir puede enseñarnos que es fundamental asignar recursos dedicados a los lanzamientos. Es una buena práctica priorizar los tickets de soporte que incluso "huelan" para estar relacionados con su nueva versión y reducir la exposición de nuevos problemas tanto como sea posible.
¿Por qué (casi) no hay complementos o temas que admitan implementaciones por etapas?
En preparación para escribir este artículo, traté de preguntarle a la comunidad quién está utilizando implementaciones por etapas para obtener comentarios sobre su experiencia, lo que aprendieron, etc.
Como era de esperar, encontré solo dos empresas de WordPress en mi red que han configurado lanzamientos por etapas como parte de su ciclo de lanzamiento. Muchos desarrolladores ni siquiera conocían el concepto, y el resto no lo usa porque su solución de distribución no lo admite (o pueden haber pensado en desarrollarlo y no tienen tiempo).
La mayoría de los desarrolladores de complementos y temas que no venden a través de Freemius venden desde su sitio web a través de EDD o WooCommerce, que no admiten lanzamientos por etapas. Aquellos que venden a través de mercados como CodeCanyon y ThemeForest tampoco tienen una solución lista para usar, y lo más probable es que nunca la tengan.
Incluso los desarrolladores que conocen el concepto no tienen más remedio que desarrollar su propio mecanismo para respaldar los lanzamientos por etapas. Este desarrollo de infraestructura suele ser muy difícil de priorizar dentro de una empresa de productos.
Suscríbase y obtenga una copia gratuita de nuestro
Complemento de WordPress Libro de negocios
Exactamente cómo crear un próspero negocio de complementos de WordPress en la economía de suscripción.
Comparte con un amigo
Introduce la dirección de correo electrónico de tu amigo. Solo les enviaremos este libro por correo electrónico, honor del explorador.
Gracias por compartir
Impresionante: se acaba de enviar una copia de 'El libro de negocios de complementos de WordPress' a . ¿Quieres ayudarnos a correr la voz aún más? Adelante, comparte el libro con tus amigos y colegas.
¡Gracias por suscribirte!
- Acabamos de enviar su copia de 'El libro de negocios del complemento de WordPress' a .
¿Tienes un error tipográfico en tu correo electrónico? haga clic aquí para editar la dirección de correo electrónico y enviar de nuevo.
¿Cómo le dan una ventaja comercial los lanzamientos por etapas?
Dado que casi nadie aprovecha los lanzamientos por etapas en este momento, si comienza a utilizarlos y los comercializa correctamente en su sitio web para que los visitantes sepan que tiene ciclos de lanzamiento responsables, definitivamente le brinda una ventaja competitiva y aumenta la confianza en su producto. /¡marca!
Si analiza el mercado desde la perspectiva de un desarrollador, notará que muchos desarrolladores siguen de cerca a sus competidores y, por lo general, establecen sus precios dentro del rango de precios del mercado en su vertical, lo que lleva a que los productos de WordPress de la competencia ofrezcan características similares en el mismo rango de precios.
Desde la perspectiva del comprador, eso significa que a menudo es difícil saber qué producto comprar porque todos tienen características y precios comparables. Pero, cuando evalúa varios complementos que cuestan lo mismo y, más o menos, tienen las mismas características, ¿no se inclinaría por el producto que ofrece lanzamientos por etapas sabiendo que sus lanzamientos de producción deberían ser más estables que los de la competencia?
Los lanzamientos por etapas aumentan la confianza en su producto y negocio. Es una ventaja que puede aprovechar antes de que los lanzamientos por etapas se conviertan en una práctica estándar (lo que realmente espero que lo hagan).
Freemius ahora admite implementaciones por etapas para complementos y temas pagos
Estamos entusiasmados de ser pioneros en los lanzamientos por etapas en el ecosistema premium de complementos y temas de WordPress. Nuestros socios de ventas ahora pueden lanzar actualizaciones de manera segura, confiable y confiable, con un retroceso mínimo para sus usuarios o recursos de soporte/desarrollo.
Sabemos lo desafiantes y estresantes que pueden ser los lanzamientos importantes, especialmente porque siempre existe el riesgo potencial de afectar negativamente a su marca después de un lanzamiento de "Clusterbug".
Con los lanzamientos por etapas implementados, existe una red de seguridad para la sustentabilidad y defensa de la marca de nuestros socios, y se alivia el estrés innecesario asociado con los lanzamientos a una gran base de usuarios.
Esto va de la mano como un beneficio para los clientes de nuestros socios. Cuando los usuarios compran productos vendidos a través de Freemius, ahora pueden estar seguros de que están optando por una solución impulsada por Staged Rollouts y pueden esperar lanzamientos mucho más estables de complementos y temas premium que utilizan el mecanismo.
Si está vendiendo con Freemius, aquí le mostramos cómo usar correctamente nuestro mecanismo de lanzamientos por etapas.
¿Cómo ha implementado Freemius los lanzamientos por etapas?
Cada sitio web que activa una licencia para desbloquear un complemento o tema premium obtiene un registro en nuestra base de datos. Lo primero que hemos hecho es introducir una nueva propiedad last_served_update_version para almacenar la última versión del producto que se puso a disposición de un sitio web.
Luego, enriquecimos la tabla responsable de almacenar los datos de publicación con dos nuevas propiedades: limit , uniques .
Cuando un desarrollador marca una versión como lanzada, se le solicitará el siguiente cuadro de diálogo, lo que le permitirá configurar el porcentaje (o número) de sitios web que tienen una licencia activa en los que desea implementar la versión paga:
Si establecen un lanzamiento de lanzamiento limitado, el sistema contará el total de sitios web activos con una licencia activa y luego establecerá la nueva propiedad de limit del lanzamiento en consecuencia.
Finalmente, actualizamos el extremo de la API llamado por los sitios web para verificar si hay una nueva versión e introdujimos la siguiente lógica (en pseudocódigo):
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
Este algoritmo asegura que:
- La exposición del lanzamiento está limitada según el porcentaje establecido del lanzamiento.
- Si la versión anterior todavía está preparada, es decir, nunca estuvo expuesta a toda la base de instalación, los sitios web que recibieron la versión preparada anterior se expondrán primero a la última versión preparada.
A diferencia de la arquitectura de lanzamientos por etapas de WPML, que garantiza que cada versión irá a un subconjunto diferente de su base de instalación mediante contenedores lógicos, nuestra implementación se basa en la aleatoriedad. Por lo tanto, un sitio web puede obtener dos lanzamientos en etapa inicial en dos ciclos de lanzamiento consecutivos. Sin embargo, el beneficio de este enfoque es que pudimos enviar implementaciones por etapas a todos los clientes de nuestros socios sin la necesidad de impulsar una actualización de SDK, que puede tardar muchos meses, incluso años, en propagarse a todos los clientes.
¿Por qué los lanzamientos por etapas son esenciales para el futuro de WordPress?
Cuando le pregunté a Amir cuál fue su motivo para desarrollar lanzamientos por etapas para los ciclos de lanzamiento de WPML, esto es lo que me dijo:
Hace 3 años, en WordCamp Europa, pasé un tiempo charlando con los clientes de WPML para recopilar todo tipo de comentarios sobre su experiencia general. La frustración n.° 1 que encontré fue que nuestros clientes tenían miedo de actualizar el complemento, ya que puede romper inesperadamente su sitio.
Amir Helzer,
Fundador de OnTheGoSystems (WPML, conjunto de herramientas)
Me identifico absolutamente con eso.
Nuestra política interna en Freemius cuando se trata de actualizar complementos y temas es... ¡simplemente no lo hagas! Con dos excepciones: si hay un problema de seguridad conocido o una función que está disponible en una versión más reciente que necesitamos para nuestro sitio.
Nuestra política de actualizaciones fue “escrita con sangre” después de varios incidentes de actualizaciones que salieron mal y causaron dolores de cabeza inesperados y pérdida de tiempo, interrumpiendo nuestra operación y plazos. Y sí, podríamos haber evitado parte del estrés con un entorno de preparación, pero esto no nos habría ahorrado tiempo ni molestias si aún queríamos continuar con la actualización a producción.
WordPress ha evolucionado un poco desde entonces, y ahora tenemos la desactivación automática cuando fallan los complementos. Sin embargo, eso no se aplica a los temas y la desactivación de un complemento de misión crítica para nuestro sitio web sigue siendo un gran problema.
La conclusión es que si yo, como desarrollador de complementos y CEO de una empresa que ayuda a miles de desarrolladores de complementos y temas a hacer crecer sus negocios, me preocupa romper nuestro sitio cada vez que actualizamos complementos o temas en nuestro sitio, entonces eso ciertamente significa la mayoría de los usuarios no confían en actualizar el software en nuestro espacio.
La falta de implementaciones por etapas nos detiene a nosotros y a todo el ecosistema de WP y brinda a las soluciones de la competencia basadas en SaaS una ventaja considerable. ¡Los usuarios de WiX y Shopify no necesitan pensar en actualizaciones en absoluto! Las actualizaciones simplemente suceden para ellos en segundo plano, y su software siempre está actualizado, en cuanto a seguridad y características.
La falta de implementaciones por etapas frena todo el ecosistema de WP y brinda a las soluciones basadas en SaaS una ventaja considerable. Los usuarios de WiX y Shopify no necesitan pensar en las actualizaciones de software, simplemente suceden en segundo plano.Tweet
Si vio el Estado de la palabra de la semana pasada, el cofundador de WordPress, Matt Mullenweg, entiende claramente la importancia de un software actualizado. Aquí está la visión de Matt para las actualizaciones de WP:
… lo que le permite optar por las actualizaciones automáticas para Core. Este es el primer paso para nuestro objetivo: permitir que su WordPress se mantenga esencialmente solo, cuando puede configurarlo y olvidarlo, y obtendrá actualizaciones automáticas, en segundo plano y sin problemas para todos sus complementos, temas y núcleo.Tweet
La única forma en que puedo imaginar que WordPress se convierta en un "establecer y olvidar" es si las actualizaciones de software pueden ser más confiables y confiables, y eso solo puede suceder con los lanzamientos por etapas.
WordPress.org: así es como puede introducir implementaciones por etapas para el repositorio de complementos y temas
Similar a nuestra implementación, se deben agregar dos nuevas meta opciones a cada complemento y lanzamiento de tema en la base de datos de WordPress.org: limit y uniques .
La edición de la meta opción de limit se puede exponer en la Vista avanzada para el propietario registrado (y tal vez para otros confirmadores):
Un desarrollador tendrá una forma de controlar la exposición de cada lanzamiento, así como la capacidad de establecer un límite para el próximo lanzamiento.
Dado que WordPress.org no almacena datos estructurados para cada sitio web que recibe actualizaciones de WordPress.org, en lugar de almacenar la última versión "vista" por un sitio web en la base de datos de WordPress.org, el almacenamiento de los datos se puede delegar a los sitios web. . Esto significa que el transitorio 'update_plugins' y los datos enviados a la API de WordPress.org al buscar actualizaciones deberán enriquecerse con una last_served_update_version .
Finalmente, los puntos finales de API de actualizaciones de WordPress.org se pueden enriquecer con la misma lógica que usamos para la implementación de Freemius Staged Rollouts. Solo que en lugar de depender de la versión de la last_served_update_version de la base de datos de wp.org, el mecanismo dependerá del valor enviado desde el sitio web por el núcleo.
Fácil, ¿no?
está contratando 
Recuperemos la confianza de los usuarios para presionar el botón Actualizar
¡Todos queremos ver que WordPress tenga éxito y crezca constantemente y mejor!
Con tantos recursos destinados a Gutenberg, está claro que el liderazgo de WordPress reconoce que tenemos que hacer que la plataforma sea mucho más accesible para el Joe promedio que no es técnico. La cuestión es que, mientras no se pueda confiar en las actualizaciones de software, incluso con Gutenberg y todos los increíbles creadores de páginas que tenemos disponibles, una persona que no sea experta en tecnología se escapará a Wix en su primera actualización defectuosa, y no puedo culparlo. ellos.
Estoy llamando al fundador de EDD, Pippin Williamson, al CEO de WooCommerce, Paul Maiorana, y al equipo de WordPress.org: Tenemos la oportunidad de hacer que el ecosistema de complementos y temas sea mucho más estable para la gran comunidad de WordPress. Permitamos a los usuarios mantener su software seguro y actualizado con menos miedo y frustración. Si bien puede no parecer una alta prioridad a corto plazo, estoy seguro de que todos nos beneficiaremos a largo plazo.