¿Qué tan similares deben ser los entornos de PreProd y Prod?

Recientemente estuve en un proyecto y durante el lanzamiento, nos dimos cuenta de que no funcionaba en Producción. Funciona en todos los demás entornos, pero debido a que tenemos un equipo de lanzamiento separado y no podemos configurar los servidores y los entornos nosotros mismos, no tenemos visibilidad de la configuración en ellos.

Sospechamos que Prod tiene algunos permisos de usuario en su cuenta o configuración de IIS que son diferentes, por lo que estamos trabajando ahora.

Así que creo que todo esto ha sido una experiencia de aprendizaje para mí y no quiero que se repita lo mismo otra vez. Me gustaría preguntar, ¿qué tan diferentes deberían ser estos entornos? Siempre pensé que PreProd debería ser una copia idéntica al entorno de Prod usando una copia de la misma base de datos, usando una copia de la misma cuenta de usuario, debería instalarse en los mismos servidores, etc.

Pero, ¿hasta dónde debo llevarlo? Si el sitio web está orientado externamente, ¿PreProd debería estar orientado externamente? ¿Qué sucede si el sitio web tiene componentes que no requieren una cuenta de usuario o contraseña para navegar? ¿Todavía está bien exponerlo al mundo exterior?

Sin duda, debería probar en un entorno que sea idéntico a sus servidores de producción en la medida de lo posible. Si no lo hace, no está probando lo que usarán sus clientes. Por lo menos, necesita un entorno de este tipo para probar los informes de errores.

Obviamente habrá cosas que no querrás que sean idénticas: los enlaces a los sistemas de pago te vienen a la mente, pero debes burlarte de ellos como si fueran reales . También hay cosas que no puede replicar: la escala del sistema.

Es posible que desee probar a través de una URL externa; de nuevo, está probando lo que verán sus usuarios. Además, las pruebas a través de una URL externa utilizarán la red de manera diferente al uso interno del sistema. Los permisos (por ejemplo) desempeñarán un papel al igual que el ancho de banda disponible, los cortafuegos, etc. Todos los usuarios se enfrentarán, pero los omitirá si accede directamente al sistema.

Sin embargo, no veo un problema con los componentes que no requieren una cuenta y contraseña. Si no necesita una contraseña, entonces no es vital / sensible, si es sensible, ¿por qué no tiene una contraseña?

Creo que la mejor práctica para esto es el enfoque de Blue Green Deployment, acuñado por Jez Humble y David Farley en su libro Continuous Delivery y descrito por Martin Fowler en su publicación de blog Blue Green Deployment .

La premisa es muy simple. Del post de Martin Fowler:

El enfoque de implementación azul-verde ... [asegura] que tenga dos entornos de producción, lo más idénticos posible. En cualquier momento, uno de ellos, digamos azul para el ejemplo, es en vivo. A medida que prepara una nueva versión de su software, realiza su etapa final de prueba en el entorno verde. Una vez que el software funciona en el entorno verde, cambia el enrutador para que todas las solicitudes entrantes vayan al entorno verde: el azul ahora está inactivo.

La implementación azul-verde también le brinda una forma rápida de retroceder: si algo sale mal, cambie el enrutador a su entorno azul.

Este enfoque resolvería su problema de no tener entornos idénticos de preproducción y producción, así como también optimizar su estrategia de implementación.

Nuestro entorno de preproducción final es simplemente uno de los servidores en vivo sacados del balanceador de carga. Implementamos nuestra compilación de preproducción (que es básicamente idéntica a la compilación en vivo, aparte de las cadenas de conexión de la base de datos y un par de otros cambios de configuración) y lo probamos. Si eso funciona bien, implementamos el código en vivo, y finalmente si eso demuestra que estamos bien, devolvemos el servidor al equilibrador de carga e implementamos la compilación de producción en los servidores restantes uno por uno.

Deben ser lo más similares posible, para que pueda identificar los problemas en cualquier punto del sistema, con la posible excepción de la imposibilidad de escalar. Si es posible, la única diferencia entre su entorno de producción y el entorno de preproducción / preparación / prueba sería el tamaño: esperaría que un entorno de producción constara de muchas más máquinas en un entorno a gran escala. Incluso debe reflejar las dedicaciones de las máquinas que tiene, como servidores de bases de datos, servidores web, etc.

Sin embargo, una replicación exacta podría no ser posible bajo su presupuesto actual. Cuanto más cerca se encuentre, más efectivas serán las pruebas y los problemas menos probables surgirán durante un impulso a la producción.

Tomo una postura diferente a la de ChrisF si este entorno debe ser público. Yo digo que no debería ser. Optaría por ejecutar una copia de las bases de datos reales, o al menos una copia de un subconjunto de las bases de datos en vivo reales y un entorno interno. De esta forma, puede probar datos reales y realistas y no preocuparse por los agujeros de seguridad que conducen a una fuga. Por supuesto, puede desinfectar los datos, pero eso podría eliminar algunos "datos sucios" del entorno que podrían conducir al descubrimiento de un defecto en un sistema en vivo.

En todos los lugares donde trabajé bancos, telecomunicaciones, etc., la producción previa era una copia directa de la producción, excepto que la base de datos tendría una semana de antigüedad. Fue un proceso masivo para mantener los datos a través de pre-prod, pero se consideró esencial para las empresas para las que trabajé que implementaron pre-prod.

En la sección de banca de la UA, el gobierno multa a los bancos por fallas en el servicio, por ejemplo, cajeros automáticos de sitios web, etc., caen cada minuto. No es raro escuchar que un equipo de desarrollo / prueba fue despedido por un incidente. Pre-prod no es para todas las empresas o procesos de desarrollo, pero es esencial para algunos.