Actualiza tus lanzamientos

Henry Ford dijo una vez: "El mejor auto es un auto nuevo". Entonces, en el grupo de compañías Tinkoff pensamos en los lanzamientos de software. La inercia en el proceso de entrega de características y soluciones urgentes tarde o temprano conduce a una gran deuda técnica para el cliente y, a menudo, termina con el estancamiento del proyecto en su conjunto.

Garantizar un indicador de tiempo de comercialización elevado mientras se mantiene la calidad no es una tarea fácil. Desde mi punto de vista, es imposible construir inmediatamente rieles en los que sea posible entregar cambios rápida y convenientemente muchos meses después del inicio. El crecimiento de un proyecto generalmente va acompañado de un aumento en la cantidad de personas que trabajan en él, lo que significa que crea una fuente potencial de caos en sus lanzamientos.

No vale la pena considerar nuestra experiencia como instrucciones para el éxito, pero varias ideas me parecieron lo suficientemente interesantes como para compartirlas con usted. Empecemos

El punto de partida de nuestra historia es técnicamente el siguiente. El sistema consta de varios servicios, cuya base de código es revisada por unas 30 personas, varios equipos que están divididos por áreas de negocio, por ejemplo, servicio a personas físicas y jurídicas. Intentaré ignorar los detalles técnicos y arquitectónicos del proyecto para centrarme en el proceso de lanzamiento en sí.

Trabajamos en Gitflow , por lo que el artículo será principalmente interesante para aquellos que eligieron este método de entrega en particular.

Los problemas

El primer problema que encontramos está relacionado con la automatización insuficiente de los procesos . La implementación de todas las actividades de lanzamiento en nuestro equipo está vinculada al rol de un administrador de lanzamiento (RM).

Aquí hay algunos de ellos:

1. Dejar ramas de lanzamiento y crear etiquetas.
2. Fusionarse con master y desarrollar sucursales.
3. Cree y despliegue artefactos que se incluyen en la versión.
4. Comunicación con especialistas involucrados en el proceso, por ejemplo, con QA o administradores.

Estas tareas rutinarias requieren más y más recursos a medida que el proyecto se expande (en nuestro caso, un aumento en el número de servicios), por lo que el primer paso es automatizar todo lo que se puede automatizar. Nos integramos con la herramienta CI / CD para desviar y fusionar ramas de lanzamiento, lanzar compilaciones de prueba e implementar artefactos con el botón; con herramienta de seguimiento de tareas y mensajería corporativa para la notificación oportuna del participante responsable del siguiente paso; por ejemplo, cambie el estado de la tarea y configure el enlace para enviar una notificación.

El administrador de versiones aún tendrá que resolver manualmente los posibles conflictos derivados de la fusión de sucursales, pero las versiones rápidas y frecuentes deberían reducir su número a nada.

El siguiente problema es la prueba .

Uno de los criterios de compilación para nosotros es la ejecución exitosa de las pruebas. Es habitual dividir las pruebas en al menos dos tipos: unidad e integración.

Las pruebas unitarias le permiten verificar la corrección de los módulos individuales del código fuente del programa, que en la práctica se reduce a verificar uno o más métodos que tienen una conexión lógica obvia.

Las pruebas de integración generalmente verifican la operatividad de una cascada completa de dichos módulos, es decir, el funcionamiento de una característica completa en el lado del cliente. Por ejemplo, si se implementó una interfaz de descanso en una tarea, verificaremos la operatividad de la autorización, la deserialización de la solicitud en sí, la validez de los campos transmitidos, la integración con otros servicios y bases de datos, así como la lógica de negocios en sí. A primera vista, puede parecer que tales pruebas son muy autosuficientes y pueden cubrir todas las áreas problemáticas potenciales. No es necesario comprender cómo funciona cada ladrillo individual, y la interfaz llamada encapsula toda la lógica para obtener una respuesta simple en la salida: si funciona o no.

De hecho, crean una serie de problemas diferidos, estos son algunos de ellos:

1. La participación de una gran cantidad de componentes probados afecta proporcionalmente el tiempo de montaje y la ejecución de tales pruebas.
2. Encapsular la lógica de la prueba a menudo lleva al hecho de que es difícil garantizar la exactitud del resultado de la prueba. A menudo personalizamos la prueba para el resultado, y aún más a menudo el resultado coincide con las expectativas debido a los efectos secundarios aleatorios.
3. La relevancia de los datos de prueba se pierde.
4. Las integraciones con sistemas de terceros, especialmente en entornos de prueba, a menudo caen. Esto niega el tiempo dedicado a la ejecución, ya que no siempre es obvio: esta es una caída o falla temporal causada por nuestros cambios.

Para la mayoría de los problemas, ya se ha encontrado una solución. Pero, como de costumbre, las soluciones no vienen sin restricciones adicionales o nuevos problemas.

Elegir las pruebas correctas para usted e implementarlas correctamente es una tarea muy difícil. Además, es importante lograr un equilibrio entre la calidad de la cobertura y la velocidad de construcción para optimizar sus lanzamientos.

En nuestro caso, nos decidimos por un híbrido. Continuamos planteando todos los componentes necesarios para una prueba de características completas, lavando simultáneamente todas las integraciones posibles. Para guardar los contratos de API, utilizamos Pact y para verificar la integración con la base de datos: Testcontainers .

Como resultado, este enfoque para escribir pruebas resultó en una solución al tercer problema: mucho tiempo para la prueba manual de una tarea . La estabilidad de las pruebas híbridas ha llevado a la idea de atraer a un ingeniero de control de calidad en la etapa de especificar la tarea para compilar los casos de prueba; esto permitirá que se omitan en la etapa de prueba manual. La integración con productos útiles como TestRail y Allure se ha convertido en una especie de puente entre el desarrollador y el probador. Se crea un contrato, cuya ejecución se refleja paso a paso en el informe generado durante el ensamblaje de prueba.

Queda por conectar los informes a su herramienta de seguimiento de tareas para el seguimiento transparente de tareas. Una historia clara también reducirá el tiempo que lleva compilar e implementar pruebas para futuras tareas relacionadas.

De esta manera, los ingenieros de control de calidad ahorran suficiente tiempo para concentrarse en probar casos excepcionales e integrarse con otros sistemas.

El último problema está relacionado con esto. Para las pruebas manuales, todas las tareas se fusionan desde las ramas de características en desarrollar y lanzar una implementación en el banco de pruebas.

En primer lugar, con este enfoque, no se puede hablar de pruebas puras de la función, ya que en paralelo los cambios relacionados de otros desarrolladores pueden desarrollarse.

En segundo lugar, al liberar la rama de lanzamiento, puede resultar que el control de calidad no haya tenido tiempo de probar algunas de las tareas. Hay una opción: revertir los cambios afectados por estas tareas o ralentizar el lanzamiento hasta el final de la prueba.

Tendrá que hacer esa elección todo el tiempo, a menos que aísle su entorno de prueba . Es importante que no haya cambios en el componente bajo prueba que no sean los realizados por la tarea. En nuestro caso, necesitamos poder recoger uno o más servicios cuyas sucursales hayan recibido cambios y administrar el enrutamiento dentro del clúster enviando solo las solicitudes que necesitamos de QA a estas instancias. La tarea es complicada si ya se utilizan mecanismos de equilibrio en el clúster, que también deben tenerse en cuenta.

Al aprovechar esta oportunidad, comenzamos a realizar pruebas manuales directamente en ramas de características separadas: implementar el servicio deseado durante la prueba, integrándolo en el entorno general de forma aislada. Al fusionar solo tareas preparadas en la rama de desarrollo y deshacernos de los bloqueos, nosotros mismos comenzamos a determinar qué cambios deberían incluirse en el lanzamiento y cuáles no.

Vale la pena señalar que es poco probable que tal solución se convierta en una bala de plata para aquellos equipos que realizan cambios en casi los mismos archivos. En este caso, el almacenamiento de características es inversamente proporcional al número de conflictos que surgen durante la fusión. En la práctica, con lanzamientos bastante frecuentes, esto ocurre extremadamente raramente en un equipo con cincuenta desarrolladores.

En lugar de salida

En resumen, podemos identificar los principales enfoques que pueden ayudar a acelerar los lanzamientos:

1. Automatización de operaciones rutinarias.
2. Transparencia de procesos para todos los involucrados.
3. El equilibrio necesario entre velocidad y calidad en la escritura de pruebas automatizadas.
4. Tiempo reducido para pruebas manuales.
5. Aislamiento del entorno para pruebas.

Es importante comprender que en la elección de varios enfoques, principios y estrategias siempre vale la pena comenzar desde el contexto de su problema. Hay muchas formas igualmente confiables y más sofisticadas para acelerar la entrega de su software al cliente. Un intento de responder a las nuevas dificultades emergentes ha llevado a las conclusiones descritas anteriormente. Para nosotros, fueron el primer paso hacia un enfoque más audaz para lanzar lanzamientos .