Pruebas beta de nuevas características del website con datos en time real y clientes reales

El objective principal de esta pregunta es determinar los inconvenientes de implementar una versión ligeramente modificada de un website junto con un website en vivo.

Este website secundario estaría extrayendo de la misma database que el directo pero tendría características modificadas para probadores beta.

El objective final es permitir que ciertos clientes prueben nuestras nuevas funciones con sus datos.

Asi que:

  1. No tienen que hacer las cosas dos veces yendo a una versión copyda del sitio.
  2. Están usando sets de datos familiares

Otra posibilidad sería establecer un indicador por count de usuario para permitirles ver ciertas características, pero esto requeriría mucho trabajo adicional. Además, una vez que esté listo para su lanzamiento, deberíamos eliminar todos los controles adicionales.

Me está costando ver las desventajas de esto, pero sé que tiene que haber algo que me deslumbre. Gracias por cualquier ayuda

Versión de Git controlada, flujo de trabajo de implementación de Capistrano, marco de Cakephp, MySql Actualmente contamos con serveres locales y de testing que están separados de nuestros serveres de producción.

EDICIÓN 12-20-2012 10:30 a.m. EST

Basado en algunos comentarios y una respuesta, tengo una actualización basada en comentarios.

  1. Se deben realizar testings internas meticulosas antes de las testings de retroalimentación 'beta' / usuario. (que ya hacemos)
  2. Si tomamos estas precauciones y la base de código parece sólida, el riesgo de implementación junto con el server de producción podría ser manejable. Estamos trabajando en un marco aquí, por lo que la probabilidad de eliminación masiva y mala sql es relativamente baja.

Dicho todo esto, preferiría no tomar este enfoque porque aún tiene un riesgo inherente. ¿Alguien hace testings beta con datos del server en vivo de otra manera?

Depende…

Si se trata de una versión beta para get comentarios de los clientes, sobre un producto que se ha probado completamente y se sabe que es estable, los riesgos son relativamente manejables (aunque vea los puntos a continuación). Esta es la forma en que Google define "beta".

Si "beta" significa que el código está completo y, por algún motivo, probado, pero quién sabe qué errores hay, corre el riesgo de corromper su database en vivo. No importa qué tan inteligente sea su estrategia de respaldo, si algo sale mal, el mejor escenario posible es que los usuarios beta se enfrenten a pérdida de datos o corrupción; el peor caso es que todos sus usuarios pierden datos (he visto cláusulas "donde" rotas en las instrucciones de eliminación o actualización que causan todo tipo de daños de entretenimiento).

Otro tema a considerar es si la database es compatible con versiones anteriores y posteriores: ¿puedes migrar a tus usuarios beta a la versión convencional si no les gusta la actualización o si algo sale mal? Este es un trato mucho más grande si "beta" significa "no probado", por supuesto.

En general, es mucho más fácil tratar con la compatibilidad unidireccional, lo que permite a los usuarios actualizar, pero no degradar, otro argumento sólido para que "beta" signifique "comentarios de los usuarios" …

    Intereting Posts