Cómo lanzar una nueva versión de su producto, violando la compatibilidad con la versión anterior

Hace unos días, yo y mis colegas de Nelio estábamos discutiendo el futuro de nuestras pruebas de complemento Nelio A/B y sobre sus características y mejoras futuras. Como plataforma de prueba A/B, el complemento requiere actualizaciones continuas para mantenerse al día con las nuevas versiones de WordPress y garantizar que todo funcione como deberían. Tenga en cuenta que es el primer complemento que he lanzado para WordPress, a fines de 2013, y ha evolucionado constantemente. La llegada de Gutenberg a WordPress ha abierto nuevas posibilidades de prueba divididas. Y eso ha planteado una pregunta interesante: ¿deberíamos hacer una mejora incremental en nuestro producto o sería mejor comenzar desde cero y lanzar algo completamente nuevo, lo que aprovecha al máximo los bloques de WordPress?
Todavía no hemos decidido en qué dirección ir, pero pensé que sería interesante discutir los problemas de lanzar una nueva versión sin compatibilidad inversa y cómo podemos mitigarlos o eliminarlos. Así que hoy explicaré dos soluciones para lanzar una nueva versión de su servicio, rompiendo la compatibilidad con versiones anteriores para que sus clientes no sufran esta decisión. Una nota sobre la compatibilidad inversa como Chris Lema dijo hace algún tiempo en su blog: “La compatibilidad con la retrocompatibilidad es muy sostenida y adoptada por el proyecto WordPress. (…) [es] un valor no solo para los desarrolladores. Es un valor para los usuarios finales. Y [si está roto], el usuario final es el que recibirá el mensaje de que su sitio ya no funciona “.

Asegúrese de que sus usuarios no terminen con un complemento que no funcione.
Entonces, ¿qué significa exactamente romper la compatibilidad con la retrocompatibilidad? ¿Cómo podemos romperlo? Aquí hay algunos ejemplos: cambiar la API con la que se puede extender nuestro complemento (funciones, ganchos, etc.).
Modificación de la estructura de la base de datos.
Cambiar la API de nuestra nube (si nuestro complemento usa uno).
La transición a un nuevo modelo de negocio y, por lo tanto, la transición a un nuevo paradigma de actualizaciones, características, etc.
Considere, por ejemplo, nuestro servicio de prueba A/B. Aproximadamente así es como funciona:
El usuario puede crear pruebas A/B en su sitio web. Esencialmente, una prueba A/B consiste en la página que desea probar, una o más variantes de esa página y los objetivos de conversión que intentamos mejorar. Toda esta información se almacena en WordPress.
Un componente en la nube es responsable de ver visitas en un sitio web utilizando las pruebas Nelio A/B. Similar a lo que hace Google Analytics, este componente recopila información, procesa y genera un resumen de los resultados digeridos. Y, al igual que GA, estos datos se envían utilizando un script de seguimiento.
Finalmente, hay una visualización en el complemento que se conecta a esta nube a través de una API. La visualización atrae los resultados digeridos y muestra al usuario algunas estadísticas y gráficos.
Un complemento como la prueba Nelio A/B puede cambiar de muchas maneras y, si no tenemos cuidado, uno de estos cambios podría conducir a un “enchufe roto”. Por ejemplo, supongamos que queremos/necesitamos actualizar la API de nuestra nube. En este caso, nos vemos obligados a actualizar nuestro complemento, porque el script de seguimiento y la visualización de los resultados dependen de esa API. Por lo tanto, una nueva API requiere un nuevo complemento. Pero aquí está el problema: esta nueva API también significa que nuestros usuarios ahora están obligados a actualizar, porque las versiones anteriores de nuestro complemento no podrán comunicarse con la nueva API. Calienta ahora: un complemento que ha funcionado sin problemas y Sin costura, ya no funciona debido a una actualización que hiciste en la nube. No frío. No es en absoluto posible la violación de las soluciones de la compatibilidad inversa no es un problema trivial. Es algo que requiere un análisis cuidadoso. Y, en cualquier caso, lo más importante es optar por una solución que no deje a los usuarios actuales con un complemento que no funcione. Especialmente aquellos que le pagan por su servicio. Si estamos seguros de que lo que nos convenga mejor como un profesional independiente o como empresa, por cualquier razón, es comenzar desde cero con una versión completamente nueva de nuestro producto y deshacerse de la retrocompatibilidad, hay dos soluciones. Con ellos, podremos hacer una lista limpia, asegurándonos de que nuestros usuarios continúen usando lo que tenían antes.
Inicie un nuevo producto (registro) La primera solución que tenemos para iniciar una versión que no es compatible con la versión inversa no es hacer esto. En cambio, ¡lanza un nuevo producto! !
Al iniciar un producto separado, evitamos romper la compatibilidad con la versión anterior, pero nos vemos obligados a pedir a los usuarios que se muden a la nueva versión. Esto garantiza que los usuarios actuales tienen un enchufe operativo que funciona como de costumbre. De hecho, nunca podrán actualizar a una versión que “rompe las cosas”, simplemente porque esa nueva versión nunca existirá; Inicie un complemento completamente nuevo y haga esfuerzos para actualizar este nuevo complemento, lo que significa que están “congelados en el pasado”.
Esto, por supuesto, plantea algunos problemas serios para abordar:


Los usuarios que ya tenemos no sabrán que hay una nueva versión de nuestro producto, si no les decimos. Esto significa que tenemos que promover el “nuevo complemento/servicio” en el anterior, lo que parece extraño … pero funciona bien.
Lanzar un nuevo producto es muy difícil. Todo el esfuerzo que realizó con el producto anterior (creando una marca para él, su posicionamiento, obtención de reseñas, instalaciones activas …) se pierde y se ve obligado a comenzar desde cero.
Esta es una solución de suscripción: lanzamos un nuevo producto e invitamos a que no use el viejo y obtenga el nuevo producto. Esto es lo que hizo WordPress (de alguna manera) hace unos meses, cuando lanzó a Gutenberg como complemento: usted fue quien decidió si desea usar Gutenberg en su sitio instalando el complemento en su sitio.
Iniciar una actualización que viola la compatibilidad con la versión anterior (exclusión por fuera) Otra opción es el enfoque inverso o la solución de resignación: inicie una actualización a su producto que rompe la compatibilidad con la versión anterior y, en paralelo, inicie un nuevo producto con la versión anterior.. De esta manera, incluso si la nueva versión no es compatible con la versión inversa, ofrecemos a nuestros usuarios una alternativa para que todo funcione como solían hacerlo. Al lanzar una nueva versión, todos los usuarios podrán ver y descubrir (Efecto WOW ). Pero si no están interesados ​​en él, también ofreceremos la opción de usar la versión anterior, que se lanzaría como un nuevo producto.
Este método resuelve los dos problemas que planteamos en la solución anterior. Por un lado, todos los usuarios sabrán desde el primer día que hay una nueva versión de nuestro producto/servicio y que pueden ver y probar lo nuevo.
Por otro lado (y quizás lo más importante), seguimos aprovechando todo el trabajo realizado hasta ahora, porque simplemente hemos lanzado una nueva versión de un producto bien establecido. Mantendrá la marca, las reseñas, las estadísticas … nada cambiará, porque no comienza desde cero. Como puede imaginar, esta es la solución de la renuncia: cada vez que un usuario actualiza su complemento, verá la nueva versión (incluso si no le gusta interrumpir la compatibilidad con la versión anterior). Pero también les da la oportunidad de regresar a la versión anterior instalando un nuevo producto. Así es como WordPress lo hizo en diciembre del año pasado cuando presentó el editor de bloques en la última actualización y ofreció a los usuarios la oportunidad de usar el editor antiguo instalando el complemento del editor clásico. En conclusión, la compatibilidad con la versión anterior no es trivial, porque puede Tener grandes implicaciones. Para sus usuarios en general, no recomendamos hacerlo. Pero a veces es la única opción que tienes. Si tiene que hacer esto, le recomiendo que implemente una de las dos soluciones que he visto hoy. Con ellos, se asegura de que sus usuarios tengan un plan de repuesto, por lo que “todo funciona como antes” y nadie se queja de “cosas rotas”. Por supuesto, como contraparte, tendrá que mantener dos productos (incluso suponiendo que la versión “antigua” tenga un mantenimiento mínimo), pero este es un tema para otra publicación.
Ahora dime, ¿alguna vez has enfrentado un problema como este? ¿Cómo lo resolviste? ¿Qué harías? Imagen presentada por DietMar Becker en Unssplash.