deployment - resultado - qfd toyota
¿Cómo implementar un despliegue de funciones limitadas(lenguaje independiente) para sus usuarios? (4)
Me gustaría conocer algunas de las mejores prácticas comunes para implementar un nuevo sitio web en un grupo selecto de la base de usuarios.
Los usuarios podrían, por ejemplo, basarse únicamente en un porcentaje de su base general de usuarios (10%). La implementación debe ser personalizable (configurable) y ser compatible con cualquier número de funciones. También sería útil asociar lanzamientos a roles o privilegios de usuario (ACL) específicos.
Entonces, en esencia, ¿qué es una arquitectura que se escalaría razonablemente bien?
En cuanto a la parte de lenguaje independiente, puede proporcionar pseudocódigo, conceptos generales o ideas, o fragmentos de su idioma preferido para transmitir su punto.
Los enlaces a cualquier ejemplo o tutorial son bienvenidos.
El optimizador de sitios web de Google parece exactamente lo que estás buscando.
En mi último trabajo, lo logramos utilizando el equilibrador de carga y una cookie de revisión actual.
El equilibrador de carga establece una cookie que identifica el número de revisión de la instancia que estaba utilizando el usuario. Si esa cookie ya estuviera presente, el equilibrador de carga simplemente enviaría esa solicitud a una instancia en ejecución con la revisión correspondiente. Cuando implementamos una nueva revisión, el equilibrador de carga continuó enviando el tráfico con una cookie de revisión existente a su revisión original hasta que esa revisión ya no se ejecutara o el usuario cerrara su navegador. El nuevo tráfico se enviaría a la revisión recién implementada. Esto nos permitió probar los cambios por un momento mientras nuestros usuarios existentes continuaban ejecutándose en la revisión anterior. También podríamos configurar manualmente esa cookie para probar la nueva revolución internamente en el entorno de producción antes de convertirle nuevo tráfico. Cuando estuvimos seguros de que la nueva revisión no tenía problemas importantes, podríamos derribar la revisión anterior y todo el tráfico comenzaría a ir a la última revisión.
Sin embargo, esa configuración no admite cambios de base de datos incompatibles hacia atrás. No hay prácticamente ninguna forma de hacerlo donde pueda tener una parte de sus usuarios en un esquema de db y otra en otra, y poder escribir escrituras en ambas y luego combinarlas de alguna manera después de que haya decidido que la nueva velocidad está bien. . Quiero decir, es posible, pero realmente depende de lo que sean exactamente los cambios de esquema y de cómo afecten su aplicación, por lo que no puede hacerlo de manera confiable y independiente en la implementación. Para nosotros, generalmente intentamos no hacer cambios de esquema incompatibles hacia atrás. Si realmente fuera necesario, intentaríamos posponer la parte destructiva (eliminando una columna o tabla) a una revisión posterior donde podríamos migrar el esquema y tener ambas versiones ejecutándose sin efectos adversos en los usuarios actuales.
Mi recomendación sería que, para las personas que reciben la nueva función, el sitio en el que se encuentran debe estar lo más cerca posible del sitio en el que todos estarán una vez que la función sea pública.
En otras palabras, no tendría, por ejemplo, la lógica condicional en una página para determinar si un botón debería estar visible o no, si esa condición solo existiría durante este período beta. Más bien, al momento de iniciar sesión, determinaría si esta persona es un participante beta o no (esa determinación podría ser aleatoria, podría hacer referencia a su rol, etc.). Si son participantes, se los redireccionará a un sitio implementado por separado que se implementa desde una rama de control de versión.
Una vez que se completa el despliegue, la rama se fusiona y todos ven la nueva función.
De esta manera, no tiene que preocuparse de que la base de códigos que ven los usuarios de la versión beta pública es diferente (de alguna manera podría romper algo) de la base de códigos de la versión final.
Para un proceso de selección aleatoria, me gusta el concepto de preguntar a cada cliente cuando tienen un inicio de sesión exitoso si desean participar en las pruebas beta, una vez que se alcanza la cantidad total requerida o deseada de usuarios, deje de preguntar. En la base de datos tiendo a almacenar a qué servidor redirigir al usuario y ejecutar un script estándar que mueve a cada usuario a la ubicación correcta al iniciar sesión.
Diseñamos nuestros meses de desarrollo de aplicaciones con anticipación y evitamos cambios en el esquema existente. La razón es muy obvia, por supuesto, esto no siempre es posible, de modo que cuando tenemos un cambio como este, siempre documentamos el cambio cuando está escrito y planificamos la migración para este campo lo antes posible. De esta manera, tenemos un plan de batalla sobre los cambios que se están realizando y podemos implementar la mejor solución posible para nosotros. Lamentablemente esto cambia dependiendo de las circunstancias.
Siempre ejecutamos múltiples entornos, tenemos producción, desarrollo y beta en general. Esto significa que no nos metemos con los servicios de producción que equivalen a dinero, no tenemos personas que rompan el código y desconecten el servicio cuando optimizamos.
El desarrollo utiliza GIT para el monitoreo de versiones y los usuarios nunca lo ven, ya que recibimos todo tipo de experimentos extraños y maravillosos cargados para jugar. También utiliza su propia base de datos frente a los datos en vivo.
Con la versión beta, generalmente migramos datos de usuarios específicos, pero recientemente hemos tenido una mejor experiencia con la duplicación de toda la base de datos y la planificación de una fecha específica para el inicio de la versión beta, lo que hace que los usuarios puedan optar por no participar en la versión beta y que otros opten por participar. con cambios mínimos requeridos para soportar esta opción. Lo que generalmente hacemos es migrar nuevos datos entre las 2 bases de datos una vez al día, los nuevos opt-ins y opt-outs solo tienen efecto desde el momento en que los datos se han migrado a la otra plataforma.
También hemos tenido éxito a pequeña escala con la base de datos de producción existente para probar algunas funciones nuevas que operaban fuera de su propia tabla, por lo que depender de lo que esté haciendo con los datos utilizando la misma base de datos en vivo podría ser una buena opción.
Espero que esto te sea útil ... buena suerte con tu compañero de pruebas.