¿Cuál es el punto de la puesta en escena?

Pensé que había resuelto esto, pero después de leer Entrega continua (excelente libro) estoy un poco confundido. Hablan de tener servidores para:

• desarrollo
• varias formas de pruebas automatizadas
• prueba de aceptación del usuario (UAT), es decir, sentarse con el cliente y mostrárselo, y dejar que haga pruebas exploratorias. Los probadores internos también podrían usar esta configuración para pruebas exploratorias.
• puesta en escena
• producción.

Siempre pensé que la puesta en escena proporcionaba la función UAT, pero parece que tienen puesta en escena como un nivel separado. Entonces, en ese esquema, ¿qué función proporcionarían los servidores de ensayo?

La puesta en escena sería poner los sistemas completos del producto en su lugar, pero aún no los está utilizando. Cuando entren en uso sería "producción". Debe colocar todo en su lugar tal como se utilizará, probar y luego activar el interruptor.

La UAT usa comúnmente un entorno de "prueba" que es significativamente diferente del hardware / software / configuración que se utilizará en la producción.

Por ejemplo, donde trabajo, los clientes prueban todo en un entorno VM que se ejecuta en nuestros servidores. Cuando su sistema entre en funcionamiento, se ejecutará en su hardware, en sus instalaciones, probablemente integrándose con sus sistemas existentes; no tendrá absolutamente nada que ver con nuestros servidores o entorno de prueba (excepto que el código y alguna configuración se han copiado desde allí ...)

Trabajo en el equipo de gestión de versiones en una gran empresa de internet. Usamos esencialmente el proceso que describió anteriormente, y hemos elegido ese proceso a propósito. En nuestra metodología, la estadificación sirve como un mecanismo de ramificación para un nivel final de prueba en producción.

Obviamente, desea hacer todas las pruebas antes de comenzar la producción, pero en un entorno grande y complejo con muchos usuarios, ese es un objetivo muy difícil de alcanzar. En particular, es prácticamente imposible cargar adecuadamente el software de prueba en QA. Las pruebas funcionales son mucho más fáciles de automatizar que las pruebas de carga. Cuando tienes miles de usuarios golpeando tus servidores, las cosas fallan de formas extrañas y difíciles de predecir.

Entonces, esto es lo que hacemos:

• Desarrollo
  • incluye integración continua y pruebas automatizadas
• prueba de lanzamiento
  • mi grupo analiza el lanzamiento en sí
  • revisando los registros de instalación
  • prueba de reversión
• QA
  • Pruebas de aceptación del usuario

Ese es el punto en el que nos ramificamos entre la puesta en escena y la producción. Utilizamos un modelo de tren para lanzamientos, con un nuevo tren que comienza cada pocas semanas. Incluso los trenes numerados van a los servidores de ensayo (que están en producción). Los trenes con números impares no.

Entre los trenes pares, los desarrolladores tienen la capacidad de enviar cambios individuales a los servidores de ensayo ( después de que QA haya probado esos cambios, por supuesto). Esto les permite validar que su software funciona como se espera en un entorno de producción real. Esto generalmente está reservado para los componentes que se consideran de mayor riesgo, no empujamos cada pequeña pieza a la puesta en escena.

Entonces, todos entienden que cuando comience el próximo tren uniforme, eliminará lo que hay en los servidores de preparación y los volverá a establecer en la línea de base del tren. Los desarrolladores se aseguran de que sus cambios entren en el tren o deciden que todavía no están listos para el uso general, en cuyo caso esos cambios simplemente se borran en los servidores de preparación.

En resumen, la respuesta breve (al menos para nosotros) es que es imposible probar completamente sistemas complejos en QA. La estadificación proporciona una forma segura de realizar pruebas de producción limitadas.

En una nota relacionada, aquí están mis diapositivas de una presentación que acabo de dar sobre cómo funciona nuestro proceso de lanzamiento.

La explicación más simple para la preparación es probar el proceso de implementación y probar usando la fuente de datos real. Algunos sistemas combinan etapas con sus entornos de prueba, pero para sistemas a gran escala, el proceso de implementación puede ser muy complejo o pueden ser pasos de prueba adicionales una vez que se conecta a la fuente de datos en vivo / producción. En estos casos, un entorno de preparación le permite probar su proceso de implementación y verificar si hay errores de última hora utilizando datos en vivo, y luego, una vez que se haya verificado que las cosas funcionan, puede cambiar rápidamente el entorno del escenario al entorno de producción.

Un ejemplo de esto sería Windows Azure, que requiere de 5 a 25 minutos para implementar una nueva versión, pero puede implementarlo en un entorno de ensayo, realizar pruebas y luego intercambiar instantáneamente los entornos de producción y ensayo .

Acabo de encontrar este artículo sobre entornos de puesta en escena que dice

La puesta en escena es donde se validan las incógnitas conocidas de sus sistemas.

Vale la pena leer el artículo completo.