Hoy estamos observando cómo el modelo de desarrollo en cascada está muriendo gradualmente en todo el mundo. No es amada por su pesadez y su pobre reacción al cambio. Esto afecta directamente la relevancia del producto y aumenta el TTM (tiempo de comercialización), lo que resulta en costos adicionales. Los desarrolladores están reconstruyendo sobre rieles ágiles, y no somos la excepción.
La metodología ágil se creó originalmente para equipos pequeños que hacen un producto llave en mano en modo de extremo a extremo y son responsables de su calidad. Pero, ¿qué sucede si desarrolla sistemas bancarios muy críticos sobre los que trabajan docenas de equipos ágiles? ¿Cómo lograr la confianza en el producto que ofrece una prueba larga e integral como en cascada? En esta publicación compartiremos nuestra solución a este problema.
Todos resuelven el problema de diferentes maneras, pero generalmente se reduce a la automatización de pruebas. Las pruebas se están desarrollando en trozos, las reglas generales para formar los trabajos pendientes de los equipos vecinos son marcos para la interacción entre equipos, como SAFe. Como resultado, debido a la sincronización de la acumulación, los equipos de productos relacionados pueden escribir y realizar pruebas juntas, incluidas las pruebas de integración. Tenemos tales marcos.
Pero ahora nos colocamos en el lugar del propietario de un sistema bancario complejo y altamente crítico. ¿Quién, después de todo, es responsable de la calidad de todo este producto si están directamente involucrados en docenas de equipos ágiles responsables por derecho propio? Debe asegurarse de que nada fallará en la producción. ¿Introducir pruebas adicionales? Hola, cascada y adiós, TTM.
No hay una solución perfecta. En esta situación, siempre tendremos un conflicto entre los principios de la metodología y la fiabilidad garantizada del resultado. Este es el compromiso que hemos encontrado.
Puertas de calidad
Si la especificidad de su producto supone que no está completamente aislado de los demás, entonces, en los puntos de contacto, debe cumplir con una regla: observe el nivel mínimo de calidad. El código debe estar cubierto por pruebas unitarias, no debe contener defectos críticos de seguridad de la información, las distribuciones deben someterse a pruebas de humo a medida que se entregan. Sin estaño, pero los requisitos son obligatorios para todos. Su implementación es un paso para las pruebas generales.
Por lo tanto, en general,
la práctica de
Quality Gates parece un conjunto de comprobaciones automáticas integradas en la canalización de DevOps de cada sistema. De hecho, refleja la tendencia a las pruebas de turno a turno, que ahora se habla a menudo en el marco de los devops.
Acordamos con todos los equipos una serie de controles, puertas de calidad, que deben pasar durante el paso de las etapas del ciclo de vida.
Codificación
Antes de construir el código, necesita un análisis estático obligatorio, verificando que el código cumpla con los estándares de un lenguaje de programación en particular. Así como la integridad de la cobertura con pruebas unitarias. Hay diferentes herramientas para esto. Por ejemplo, amamos SonarQube. Al pasar esta puerta de calidad, los equipos pueden estar seguros de que no han violado una serie de reglas básicas en una etapa temprana. Por ejemplo, se evitó una duplicación significativa, lo que aumenta la complejidad del código y la probabilidad de problemas.
La segunda prueba antes del ensamblaje es una verificación IS. Existen prácticas generalmente aceptadas para identificar problemas de SI en el código y herramientas que pueden escanear el código e identificar lugares peligrosos. Por ejemplo, una variable declarada incorrectamente puede provocar problemas en la producción. Aquí acordamos no permitir que todo lo que pueda revelarse en la etapa de escritura del código, en pentests y verificaciones más complejas.
Distribución de construcción
Al ensamblar el kit de distribución, siempre verificamos el resultado: que el ensamblaje se realizó correctamente, que todos los servicios comenzaron y funcionan como debería, que el kit de distribución se puede instalar en el entorno deseado y funcionará. Una prueba de verificación de este tipo elimina posibles malentendidos entre el probador y el desarrollador. En la práctica de la cascada, solía ser que el desarrollador terminó el trabajo, entregó la distribución a los probadores y, cuando se instaló en el soporte, resultó que el ensamblaje ni siquiera comenzó. Luego todo el ciclo se interrumpió, el desarrollo se estiró y no sucedió nada bueno.
Nuestra interacción de integración es muy complicada. Es importante no romper el estrado donde otros equipos pueden ser revisados. Podemos hacer esto debido a una distribución deficiente, y los vecinos de la cabina lo sabrán antes que nosotros, simplemente interrumpiremos todo el proceso de trabajo para ellos. Además, esto puede arruinar los datos de la prueba. Y su preparación también cuesta dinero y lleva un tiempo considerable. Especialmente cuando se trata de datos de usuario anónimos.
Pruebas de humo
A medida que el kit de distribución se instala en cada banco de pruebas, pasa una serie de pruebas de humo simples. En el banco de pruebas del sistema, se prueba la funcionalidad de la distribución. Además, el kit de distribución se coloca en el banco de pruebas de integración, donde se prueban las interacciones de integración. También ejecuta un conjunto de pruebas de humo. Si la distribución no los supera, no puede pasar a la siguiente etapa.
Usando estas puertas de calidad, obtenemos una idea inicial de la calidad de la distribución. Si las pruebas de humo fueron exitosas, el equipo comienza las pruebas. Si el kit de distribución no pasó las pruebas de humo en esta etapa, lo más probable es que no pase las pruebas manuales. Aquí lo asignamos solo si el ensamblaje está potencialmente listo para ir al baile de graduación.
Puertas de calidad como marco
Nos esforzamos por garantizar que las puertas de calidad se conviertan en un marco completo para gestionar la calidad del desarrollo de una gran cantidad de productos en forma ágil. Si un equipo no pasa constantemente ni siquiera las puertas de calidad obligatorias, esto es una señal de que hay problemas que deben discutirse y resolverse. Por otro lado, si algún equipo ya ha dominado las puertas de calidad básicas y las ha incorporado en procedimientos internos, puede ir más allá e incluir puertas de calidad adicionales.
En el futuro, planeamos implementar nuevos conjuntos de puertas de calidad obligatorias. Y también opcional, para que cada equipo con un nivel de madurez suficiente pueda elegir lo que necesita. Por ejemplo, si desea determinar la estabilidad del paquete de distribución en los sitios de prueba de integración, el equipo solo tendrá puertas de calidad. Si necesita asegurarse de que un ensamblaje complejo y de múltiples componentes no impida la implementación, otros lo tomarán. Alguien tiene un sesgo hacia la seguridad en el frente, alguien hacia comprobaciones de pruebas de carga, disponibilidad de stands, respuesta, alguien por delante de la integración o verificación de algunos datos. Cada equipo podrá encontrar puertas de calidad para su caso.
Es importante tener en cuenta que las puertas de calidad no son un sustituto de las pruebas, sino
una herramienta de control principal . Nadie cancela las pruebas. La tarea principal aquí es minimizar el daño a otros equipos debido a la mala calidad del producto lo antes posible.
Un ejemplo de una tubería de terceros que incluye puertas de calidad.Resultados de la implementación de puertas de calidad.
En primer lugar, hemos aumentado la estabilidad del ciclo de producción. Un cambio en la acción, podemos detectar de inmediato errores críticos de funcionalidad. Se gasta menos tiempo en varias iteraciones de prueba; se detectan defectos anteriores, por lo que su eliminación es más barata.
El tiempo de entrega ha disminuido: el tiempo desde el comienzo de la codificación de características hasta su implementación en producción. La estabilidad de la fase de ingeniería de TTM ha aumentado debido al hecho de que hemos reducido el tiempo de inactividad en el proceso de entrega del kit de distribución al entorno industrial. Pasamos el mismo tiempo para las pruebas, pero no tenemos ningún tiempo de inactividad debido al colapso del stand, la necesidad de esperar a que se reconstruya la distribución.
El tiempo disponible para probar entornos ha aumentado. Antes, podías armarlo y olvidarte de él durante una semana. Mientras tanto, los equipos relacionados no se pudieron probar en este entorno, porque su construcción es defectuosa y lo sabrá solo después de una semana. Ahora, cuando coloca el ensamblaje en el suelo, usted mismo lo prueba para detectar los problemas más comunes, si es necesario, retroceda, termine y devuélvalo. Y la posibilidad de no detener a nadie se vuelve mucho mayor. La introducción de puertas de calidad también conducirá a una reducción en el costo de restaurar stands y volver a entrenar los datos de prueba.
Tu opinion
Como dijimos al principio, la contradicción entre los principios del desarrollo ágil e integrado no puede cortarse como un nudo gordiano. Uno solo puede esforzarse para asegurarse de que traiga la menor cantidad de problemas posible. En nuestro caso, la práctica de puertas de calidad ayuda, pero, por supuesto, no la consideramos ideal. ¿Cómo resuelves este problema? Sería muy interesante para nosotros discutir este tema.
Nikolay Vorobyov-Sarmatov, Sberbank-Technology, Sberworks
¡Gracias a Mikhail Bizhan por la ayuda en la preparación del artículo!