Patrones de CI / CD y antipatrones. Parte 2

Buenas tardes Hoy compartimos con ustedes la traducción de la segunda parte del artículo "Patrones y antipatrones de CI / CD" , dedicada al lanzamiento de una nueva transmisión en el curso "Prácticas y herramientas de DevOps" . La primera parte de este artículo se puede leer aquí .

1.3 Patrones y antipatrones en pruebas

1.3.1 Automatización de pruebas

• Patrón: automatice la validación y validación del software al incluir unidades de prueba, componentes, capacidad, funcionalidad e implementación.
• Anti-patrones: prueba manual de unidades, componentes, despliegue, etc.
• Unidad- Automatización de pruebas sin dependencias.
• Componente: Automatización de pruebas con dependencias de otros componentes, bases de datos y sistemas de archivos.
• Implementación: automatice las pruebas para verificar la implementación y configuración exitosas. Esto a veces se llama prueba de "humo".
• Funcional: Automatización de pruebas para verificar el comportamiento del software desde el punto de vista del usuario.
• Capacidad: automatización de pruebas de carga y rendimiento en condiciones cercanas a las operativas.

1.3.2 Aislamiento de datos de prueba

• Patrón: utilice transacciones para pruebas dependientes de la base de datos (por ejemplo, pruebas de componentes) y revierta las transacciones cuando se complete. Use un pequeño subconjunto de datos para probar el comportamiento de manera efectiva.
• Anti-patrones: uso de una copia de los datos de producción para las pruebas de la etapa de compromiso. Ejecución de pruebas en una base de datos común.

1.3.3 Pruebas paralelas

• Patrón: en paralelo, ejecute varias pruebas en instancias de hardware para reducir el tiempo dedicado.
• Anti-patrones: ejecutar pruebas en una sola máquina o instancia. Ejecución de pruebas dependientes que no se pueden ejecutar en paralelo.

1.3.4 Estabilidad del sistema

• Patrón: utilice apéndices para simular sistemas externos para reducir la complejidad de la implementación.
• Anti-patrones: instalación manual y configuración de sistemas interdependientes para la construcción y la implementación de Commit Stage.

1.3.5 Pruebas de extremo a extremo consideradas dañinas

La entrega continua es un conjunto de principios y prácticas holísticos destinados a reducir el tiempo de comercialización. Se basa en comentarios rápidos y confiables gracias a las pruebas. La entrega continua requiere cualquier cambio en el código, la configuración, los datos o la infraestructura para someterse a un conjunto de pruebas automatizadas y exploratorias en la tubería de implementación para evaluar la preparación operativa. Por lo tanto, si la organización quiere lograr plazos más cortos, el tiempo de ejecución de la prueba debe ser bajo y los resultados de la prueba son inequívocos.

Por ejemplo, considere el servicio de Pagos de la compañía, en el cual los pagos al final del año se envían al servicio de Pagos posterior.

El comportamiento del servicio de pago de la empresa se puede verificar durante el tiempo de ensamblaje realizando los siguientes tipos de pruebas automáticas:

• Pruebas unitarias: comparación del objetivo y la implementación al verificar módulos de código individuales.
• Pruebas de aceptación: comparación de implementación y requisitos al verificar la parte funcional del sistema.
• Pruebas de extremo a extremo: comparación de la implementación y los requisitos al verificar la parte funcional del sistema, incluidos los servicios dependientes sin propietario.

Mientras que las pruebas unitarias y de aceptación difieren en propósito y alcance, las pruebas de aceptación y de punta a punta solo difieren en volumen. Las pruebas de aceptación no incluyen servicios dependientes sin propietario, por lo tanto, la prueba de aceptación del viaje del usuario de los pagos de la compañía utilizará el sistema de prueba , que consiste en el código de la última versión de los pagos de la compañía y la puñalada de pago .

Las pruebas de extremo a extremo incluyen servicios dependientes sin propietario, por lo tanto, la prueba de viaje de extremo a extremo del usuario de los Pagos de la Compañía utilizará el Sistema de Prueba, que consiste en el último código de los Pagos de la Compañía y la versión operativa de los Pagos.

Si la estrategia de prueba es compatible con la entrega continua, entonces debe tener una proporción adecuada de unidad, aceptación y pruebas de extremo a extremo que equilibre la necesidad de información y retroalimentación rápida y sin ambigüedades. Si las pruebas no aportan nueva información, los defectos pasan desapercibidos. Pero si la prueba lleva demasiado tiempo, la entrega será lenta y la pérdida de ingresos aumentará.

El final de la segunda parte.

De acuerdo con la tradición establecida, estamos esperando sus comentarios y los invitamos a una jornada de puertas abiertas . La tercera parte del artículo ya está disponible aquí .