Velocidad de entregas sin incidentes: qué aporta la tercerización moderna de QA y DevOps

La disyuntiva que no debería existir

La mayoría de las organizaciones de ingeniería experimentan la velocidad de entregas y la confiabilidad como fuerzas opuestas. Lanza más rápido y lanzas más errores. Lanza con cuidado y lanzas despacio. Los equipos terminan lanzando con poca frecuencia, lo que hace que cada entrega sea más grande y más riesgosa, lo que los lleva a lanzar aún menos seguido. Es una trampa que se refuerza a sí misma, y limita el plan de trabajo con la misma certeza que cualquier brecha de recursos.

La trampa no es una ley de la naturaleza. Es un síntoma de infraestructura ausente: pruebas poco confiables y entregas manuales de todo o nada. Arregle la infraestructura y la disyuntiva se disuelve. Esto es lo que la tercerización moderna de QA y DevOps, bien hecha, realmente aporta.

Confianza antes que cobertura

El instinto cuando la automatización de pruebas es débil es agregar más pruebas. Suele ser el primer movimiento equivocado. Un conjunto de pruebas en el que los ingenieros no confían, uno que falla de forma intermitente por motivos ajenos a defectos reales, es peor que un conjunto más pequeño y confiable, porque los ingenieros aprenden a volver a ejecutar los fallos en lugar de investigarlos, y los fallos genuinos se descartan como inestabilidad.

El primer movimiento correcto es hacer confiable el conjunto existente. Baje la tasa de inestabilidad hasta que una compilación en rojo signifique de forma fiable un problema real. Solo entonces amplíe la cobertura, y amplíela donde el riesgo realmente vive, guiado por el historial de incidentes en producción y la rotación del código en lugar de perseguir un porcentaje de cobertura. Un conjunto confiable con cobertura moderada lo protege mejor que uno en el que no se confía con cobertura alta.

Desacoplar las entregas del riesgo

La segunda mitad de la respuesta es la entrega progresiva. Los indicadores de funcionalidad, los despliegues canario y la reversión automática separan el acto de desplegar código del acto de lanzar una funcionalidad a los usuarios. Un cambio puede ir a producción detrás de un indicador, exponerse a una pequeña porción del tráfico, observarse, y revertirse al instante si algo está mal, todo sin un ciclo de entrega completo.

Esto es lo que permite que la frecuencia de entregas suba sin que la gravedad de los incidentes suba con ella. Cuando una entrega conlleva un riesgo para toda la plataforma, los equipos lanzan rara vez. Cuando el riesgo se desacopla y es reversible, lanzan de forma constante y segura. Las organizaciones pasan de un puñado de entregas al mes a entregas semanales por equipo o mejor, mientras los defectos críticos que se escapan bajan en lugar de subir.

Por qué el nearshore encaja en este trabajo

QA y DevOps son intensivos en colaboración. Viven dentro de las ceremonias del equipo de ingeniería, su respuesta a incidentes y sus decisiones de arquitectura. Por eso la zona horaria importa tanto para estas funciones en concreto. Un equipo nearshore en Colombia, en el mismo día laboral que una organización de ingeniería norteamericana, participa en lugar de traspasar. Y las mejores relaciones se estructuran de modo que el cliente termine siendo dueño del conjunto de pruebas confiable y de la canalización de entrega, operados por sus propios ingenieros, en lugar de alquilarlos indefinidamente. La disyuntiva entre velocidad y confiabilidad es real solo mientras falta la infraestructura. Constrúyala, y podrá lanzar más rápido y romper menos al mismo tiempo.