Estrategia de prueba para el entorno de producción [cerrado]

7

En un mundo ideal, los desarrolladores / operadores están trabajando juntos como un equipo para lanzar algo a la producción.

Sin embargo, hay organizaciones con limitaciones para que los ingenieros / equipos de lanzamiento se mantengan completamente alejados de los equipos de desarrollo / proyecto.

Esto no solo agregó el dolor de comunicación para los lanzamientos, sino que también hizo que el entorno de producción fuera casi "invisible" para el equipo del proyecto. Hasta cierto punto, existe una "crisis de confianza" entre el proyecto y el equipo de implementación.

Incluso tenemos pruebas de aceptación / funcionales buenas y confiables en el entorno UAT, pero no estamos seguros de si el proceso de implementación se ha realizado correctamente y si todo funciona en producción exactamente como UAT. Así que la única forma en que podemos verificar esto es a través de algunas pruebas en el entorno de producción.

Algunas pruebas de humo simples podrían ser útiles para identificar problemas de conectividad.

Entonces, mi pregunta es: ¿Cuál es su opinión sobre la aplicación de todas las pruebas que tuvimos en UAT a producción (con configuración para deshabilitar los bits que no queremos que ocurran en la producción, como eliminar datos, etc.)

Si ha hecho algo similar, ¿cómo reproduce los datos en el entorno de producción sin tener pistas de auditoría contaminadas (una cosa obvia estaría basada en la cuenta, pero asumamos que no hay segregación por cuenta)?

EDITAR: no era mi intención probar el entorno de producción todo el tiempo, sino solo justo después de la implementación. Además, no dejaremos de intentar resolver el problema desde la relación raíz-desarrollo / operación. Pero al mismo tiempo quisiera explorar otras posibilidades.

    
pregunta user2001850 07.08.2014 - 00:21

2 respuestas

6

Por lo general, las pruebas se realizan fuera de los servidores de producción por tres razones:

  • Seguridad. Si algo sale mal y todos los datos de la puesta en escena se eliminan accidentalmente, no le importa. Si sucede en la producción, es ... digamos yoyoy .

  • Rendimiento. Un extenso conjunto de pruebas puede usar fácilmente el 100% de la CPU en varios servidores durante varios minutos. No puede permitirse reducir la velocidad de los servidores de producción durante unos minutos diez veces por hora.

  • Objetivo. El objetivo de las pruebas es prevenir problemas en la producción. Si encuentra un problema cuando la aplicación ya está implementada, es demasiado tarde. Además, volver a la revisión anterior puede ser complicado. Por ejemplo, ¿qué sucede si la nueva versión creó una columna en la base de datos y, mientras tanto, tiene nuevos registros donde se usó esta nueva columna?

Por estas razones, le recomendaría encarecidamente que no utilice el entorno de producción para las pruebas. Además, no creo que realizar pruebas en producción y enviar los resultados a su equipo ayude a ganarse la confianza de los administradores de sistemas; pueden percibir eso como una tentativa de eludir las limitaciones que establecen para proteger su infraestructura de su equipo .

En su lugar, aborde el problema original, es decir, la falta de confianza entre los desarrolladores y los administradores del sistema. Hasta que existan problemas de comunicación y confianza en este nivel, el proceso de prueba e implementación será doloroso, sin importar qué trucos utilice para facilitarlo.

    
respondido por el Arseni Mourzenko 07.08.2014 - 02:49
4

Siempre que haya implementado un sistema robusto de control de versiones, distribuye las pruebas para que solo tenga que confirmar la funcionalidad básica.

A modo de ejemplo, lo siguiente se realiza en los cuatro entornos (simplificado por brevedad):

  • DEV: Pruebas unitarias, algunas pruebas de comportamiento
  • FAT: Pruebas de integración, pruebas de regresión, pruebas de instalación
  • UAT: prueba de implementación a LIVE (posiblemente con datos falsos)
  • VIVO: Funcionalidad común, posibles pruebas de entorno

Entorno DEV (Desarrollo)

La atención se centra en las pruebas unitarias para probar la nueva funcionalidad, la corrección de errores y las pruebas anteriores; se pueden realizar algunas pruebas de comportamiento si es necesario para la funcionalidad nueva / modificada.

Entorno FAT (prueba de aceptación de fábrica)

Usted prueba sus instaladores y permite que sus evaluadores ejecuten la aplicación y prueben las nuevas funciones, corrijan errores y aseguren que la antigua funcionalidad no se rompa a través de las pruebas de regresión.

Entorno UAT (prueba de aceptación de usuario)

Su cliente / clientes / usuarios prueban su aplicación para asegurarse de que funciona de acuerdo con sus expectativas. Es de destacar que UAT debería ser idéntico a LIVE, por lo que lo que funciona aquí debería funcionar en LIVE.

Entorno LIVE (Producción)

Solo necesita obtener la actualización de la última versión y volver a verificar lo básico (pruebas de humo): puede acceder a datos, abrir informes, ver documentos, exportar / importar datos, etc.

Cuando el software llega al entorno VIVO, ha superado todos los entornos anteriores sin problemas, por lo que no es necesario volver a realizar la prueba; Si cualquier entorno falla por algún motivo, la versión del software vuelve a DEV, se realizan cambios y todo el proceso comienza de nuevo con un nuevo número de versión, p. ej. 1.2.3.0 - > 1.2.3.1 .

Usted crea confianza en su lanzamiento a LIVE al revisar cada entorno y completar las pruebas para que no tenga que volver a realizar la prueba en LIVE.

    
respondido por el Kevin Hogg 07.08.2014 - 10:26

Lea otras preguntas en las etiquetas