Prefacio
El ecosistema de pago Mir Plat.Form incluye varias docenas de sistemas, la mayoría de los cuales interactúan entre sí utilizando varios protocolos y formatos. Nosotros, el equipo de Pruebas de Integración, verificamos que estas interacciones cumplan con los requisitos establecidos.
En este momento, el equipo está trabajando con 13 sistemas críticos de misión y negocios. Los sistemas de misión crítica garantizan que Mir Plat.Form realice sus funciones principales, asegurando la estabilidad y continuidad del sistema de tarjetas bancarias ruso. Los sistemas críticos para el negocio son responsables de dar soporte a los servicios adicionales proporcionados a los clientes de Mir Plat.form, de los que dependen las actividades operativas directas de la empresa. La frecuencia de implementación de lanzamientos en PROD varía de una vez a la semana a una vez al trimestre, todo depende del sistema y de la preparación de los participantes para la frecuencia de las actualizaciones. En total, contamos alrededor de 200 lanzamientos que pasaron por nuestro equipo el año pasado.
Las matemáticas simples dicen lo siguiente: el número de cadenas probadas es N-sistemas * M-integraciones entre ellos * K-releases. Incluso usando el ejemplo de 13 sistemas * 11 integraciones * 27 versiones de lanzamiento, hay aproximadamente 3.861 posibles opciones de compatibilidad del sistema. La respuesta parece obvia: ¿autotest? Pero el problema es un poco más serio, solo los autotests no te salvarán. Dado el creciente número de sistemas y sus integraciones, así como la diferente frecuencia de lanzamientos, siempre existe el riesgo de probar la cadena de versiones del sistema incorrecta. Por lo tanto, existe el riesgo de que se pierda un defecto en la interacción entre sistemas, por ejemplo, que afecte al correcto funcionamiento del sistema de pago Mir (PS).
Naturalmente, en PRODA la presencia de estos errores es inaceptable y la tarea de nuestro equipo es reducir este riesgo a cero. Si recuerda el texto anterior, cualquier “estornudo” afecta no solo a los sistemas internos de Mir Plat.form, sino también a los participantes del mercado: bancos, comerciantes, particulares e incluso otros sistemas de pago. Por tanto, para eliminar los riesgos, seguimos el siguiente camino:
- Introdujo una base de lanzamiento unificada. Para esta tarea, el calendario de lanzamientos en Confluence fue suficiente, indicando las versiones de los sistemas instalados en PROD;
- Realizamos un seguimiento de las cadenas de integración de acuerdo con las fechas de lanzamiento. Aquí tampoco comenzamos a reinventar la rueda, la necesitaremos más. Para resolver este problema, usamos estructuras Epic en JIRA para las pruebas de integración de las versiones. Estructura de ejemplo para la versión 1.111.0 de System3:
Por un lado, todas estas acciones ayudaron a mejorar la comprensión del equipo de las integraciones probadas, las versiones del sistema y la secuencia de su lanzamiento en PROD. Por otro lado, todavía existe la probabilidad de pruebas incorrectas debido al factor humano:
- Si la fecha de lanzamiento de cualquier sistema se ha movido, entonces un miembro del equipo debe corregir manualmente el calendario y toda la estructura en JIRA, incluidas las fechas límite para completar las tareas y, posiblemente, las versiones de los sistemas probados;
- Antes de probar la integración, debe asegurarse de que el entorno de prueba consta de las versiones correctas de los sistemas. Para hacer esto, debe revisar manualmente los bancos de prueba y ejecutar un par de comandos de consola.
Además, ha aparecido un trabajo rutinario adicional, que a veces ocupa una parte importante del tiempo.
Se hizo evidente que este proceso de preparación para la prueba de integración de las versiones debe automatizarse de alguna manera y, si es posible, combinarse en una sola interfaz. Aquí es donde entra nuestra propia bicicleta que salva vidas: Sistema de Monitoreo de Pruebas de Integración o simplemente SMIT.
¿Qué opciones le gustaría implementar en el sistema en desarrollo?
1. Un calendario de lanzamiento claro con la capacidad de mostrar versiones de todos los sistemas para una fecha específica;
2. Supervisión de entornos para pruebas de integración:
- lista de entornos;
- visualización visual de bancos de pruebas y sistemas que forman parte de un entorno separado;
- control de versiones de los sistemas desplegados en bancos de pruebas.
3. Trabajo automatizado con tareas en Jira:
- creando una estructura de lanzamiento épica;
- gestión del ciclo de vida de las tareas de prueba;
- actualización de tareas en caso de un cambio en la fecha de lanzamiento;
- poner informes atractivos en tareas de prueba.
4. Trabajo automatizado con ramas en Bitbucket, es decir, la creación de ramas de lanzamiento en proyectos:
- autotest de integración;
- calentamiento automático del entorno de integración.
5. Interfaz de usuario intuitiva para ejecutar pruebas automáticas y actualizar versiones del sistema.
Que es smith
Dado que el sistema no es complicado, no nos volvimos demasiado inteligentes con la tecnología. El backend fue escrito en Java usando Spring Boot. La interfaz es React. No hubo requisitos especiales para la base de datos, por lo que elegimos MySql. Dado que es habitual que trabajemos con contenedores, todos los componentes anteriores se empaquetaron en Docker, compilando con Docker Compose. SMITH trabaja de forma rápida y fiable como otros sistemas Mir Plat.Form.
Integración
- Atlassian Jira. En el jir, las tareas para probar cada integración específica se crean, abren, llevan al trabajo y se cierran, si todas las pruebas son exitosas, se adjunta un enlace al informe de Allure en los comentarios.
- Atlassian BitBucket. , , / . “” , .
- Jenkins. Jenkins, . , , glue Cucumber.
- . . ssh.
Antes de poder mantener un calendario y monitorear el estado de los entornos en SMIT, debe crear una lista de los sistemas bajo prueba y las relaciones entre ellos. Todos los ajustes se pueden realizar a través de la interfaz web:
Después de agregar el sistema bajo prueba a la lista SMIT:
- "Golpeará" en todos los hosts de sistemas llamados SYS_CMD en la lista de entornos;
- averigua la versión de este sistema usando el comando especificado en la configuración;
- escribirá en su base de datos la versión actual de este sistema y el entorno en el que aparece.
Como resultado, SMIT contendrá información sobre todos los sistemas implementados en los entornos utilizados, incluidos sus números de versión. Con base en esta información, puede visualizar el calendario de lanzamientos.
Calendario de lanzamiento
Después de que los propietarios de los sistemas o los jefes de equipo de los equipos de desarrollo de productos nos indiquen la fecha de instalación de una nueva versión en PROD, registramos esta versión en el calendario. Resulta que esta es la imagen:
puede notar fácilmente conflictos en los que se instalan varias versiones a la vez en unos pocos días y es posible un "calor". Los propietarios de productos son notificados de estos conflictos, porque es realmente peligroso instalar varias versiones nuevas de sistemas el mismo día.
También en la página con el calendario hay una función para mostrar versiones de todos los sistemas para una fecha específica:
Vale la pena señalar que al registrar una nueva versión en el calendario, SMIT crea automáticamente una estructura Epic en Jira y libera ramas en proyectos en Bitbucket.
Estado ambiental
Otra función muy conveniente de SMITH es ver el estado actual de un entorno en particular. En esta página puede conocer el listado de sistemas incluidos en el entorno y la relevancia de sus versiones.
Como puede ver en la captura de pantalla, SMITH encontró una versión desactualizada del Sistema 4 en host-4.nspk.ru y se ofrece a actualizarla. Si presiona el botón rojo con una flecha blanca, entonces SMITH llamará al trabajo de Jenkins para implementar la versión actual del sistema en el entorno actual. También es posible actualizar todos los sistemas después de presionar el botón correspondiente.
Entornos de prueba de integración
Vale la pena contar un poco sobre cómo definimos los entornos de prueba. Un entorno es un conjunto de stands con sistemas Mir Plat.form desplegados e integración personalizada (un sistema en un stand). En total, contamos con 70 stands, divididos en 12 ambientes.
En el proyecto de autotests de integración, tenemos un archivo de configuración en el que los testers configuran entornos de prueba. La estructura del archivo se ve así:
{
"properties":{
"comment":" system property Environment. property, , System.getProperties()",
"common.property":"some global property"
},
"environments":[
{
"comment":" name, Environment common + . common1",
"name":"env_1",
"properties":{
"comment":" system property Environment. property. , System.getProperties()",
"env1.property":"some personal property"
},
"DB":{
"comment":" TestResource' DbTestResource. id, ",
"url":"jdbc:mysql://11.111.111.111:3306/erouter?useUnicode=yes&characterEncoding=UTF-8&useSSL=false",
"driver":"com.mysql.jdbc.Driver",
"user":"fo",
"password":"somepass"
},
"SYS_CMD":{
"comment":" TestResource' RemoteExecCmd. type = remote",
"type":"remote",
"host":"10.111.111.111",
"username":"user",
"password":"somepass"
}
}
]
}Además del hecho de que este archivo es necesario para que funcione el proyecto de autotest de integración, también es un archivo de configuración adicional para SMIT. Cuando solicitas actualizar información sobre entornos en SMIT, se envía una solicitud HTTP a la API de nuestro bitbucket, donde almacenamos el proyecto con autotests de integración. De esta manera, SMITH obtiene el contenido actual del archivo de configuración de la rama maestra.
Ejecutando pruebas
Uno de los objetivos de la creación de SMIT fue simplificar al máximo el procedimiento para iniciar pruebas automáticas de integración. Consideremos lo que terminamos usando un ejemplo:
en la página de prueba del sistema (en este ejemplo, Sistema 3), puede seleccionar una lista de sistemas con los que desea verificar la integración. Después de seleccionar las integraciones requeridas y hacer clic en el botón "Iniciar prueba", SMITH:
1. Forma una cola y ejecuta secuencialmente los trabajos de Jenkins correspondientes;
2. supervisa la ejecución del trabajo;
3.cambia el estado de los problemas correspondientes en Jira:
- Si el trabajo se ha completado con éxito, la tarea en Jira se cerrará automáticamente, se adjuntará un enlace al informe de encanto y un comentario que indica que no se encontraron defectos en esta integración.
- Si el trabajo falla, la tarea en Jira permanecerá abierta y esperará una decisión del empleado responsable de la integración, quien puede determinar el motivo de las fallas de la prueba. El responsable de la integración se puede ver en la tarjeta de integración.
Salida
SMITH fue creado para minimizar los riesgos de las pruebas de integración, ¡pero como equipo queríamos más! En particular, uno de los deseos era que con un clic del botón, se lanzaran las pruebas automáticas con el entorno de prueba correcto, se verificaba todo en las coincidencias de integración necesarias y se abrían y cerraban tareas en Jira junto con los informes. Qué utopía de auto-testers: dígale al sistema qué debe verificar y vaya a tomar un café :)
Resumamos lo que logramos implementar:
- Calendario de lanzamiento visual con la capacidad de mostrar versiones de todos los sistemas en una fecha específica;
- UI , , ;
- ;
- UI ;
- Epic Task Jira, Allure ;
- Bitbucket.
Por el momento, el sistema está siendo sometido a pruebas beta cerradas entre miembros directos del equipo de pruebas de integración. Cuando se eliminen todos los defectos encontrados y el sistema realice sus funciones de manera estable, abriremos el acceso a los empleados de los equipos relacionados y propietarios de productos para que puedan ejecutar nuestras pruebas de forma independiente y estudiar el resultado.
Por lo tanto, en un escenario ideal, todo lo que se necesita hacer para verificar que el sistema cumple con los requisitos de integración es ir a la interfaz web de SMIT, actualizar el sistema necesario a través de él, seleccionar todas las casillas de verificación y ejecutar las pruebas, y luego verificar que todas se hayan completado con éxito. Las tareas se crearán automáticamente, se completarán los informes de encanto, se asignarán los estados correspondientes a estas tareas.