Formación escrita en DevOps
¿Por qué establecer un proceso de revisión continua para garantizar la calidad?
Las organizaciones dependen mucho de revisiones, auditorías, inspecciones y aprobaciones justo antes de desplegar en producción. Suelen hacerlas personas que, como mucho, participan de forma indirecta en el trabajo. Peor aún, a veces los responsables de inspeccionar y aprobar entienden mal su trabajo y tiene que explicárselo justo antes de desplegar el código.
Problemas de los mecanismos de control externos
En la mayoría de las organizaciones es más fácil establecer mecanismos de control que generar confianza mutua. Por eso, entre los problemas habituales de los controles externos están añadir preguntas a los formularios de control de cambios, añadir niveles jerárquicos de aprobación y exigir más tiempo para entender y aprobar los cambios.
Los entornos de mando y control con poca confianza están condenados a repetir muchos incidentes. Se crea un círculo vicioso porque no se ve con claridad el trabajo real ni los problemas recurrentes y porque se trabaja en lotes grandes para reducir al mínimo los despliegues difíciles. Las entregas más lentas perjudican la capacidad de competir en el tiempo de salida al mercado. Cuando la información llega despacio, tarde y sin permitir actuar, los equipos no pueden aprender de sus errores.
Una organización DevOps competente sabe que quienes están más cerca del trabajo y sus problemas son quienes mejor los conocen. Por eso, añadir mecanismos externos de control y aprobación no aporta valor al flujo. Esto plantea uno de los mayores retos actuales de la dirección y el liderazgo: crear culturas de confianza en las que el trabajo sea transparente y el respeto genuino y la confianza mutua sean parte esencial del día a día.
Deje de depender de las inspecciones periódicas e incorpore las revisiones entre pares al trabajo diario. Haga que sus desarrolladores, ingenieros de operaciones y especialistas en aseguramiento de la calidad y seguridad de la información colaboren de forma continua y revisen mutuamente su trabajo para que los despliegues sean seguros.
Coordine el trabajo complejo sin mecanismos externos de control
Trabajar con un solo equipo en un proyecto ya es complejo. Puede serlo aún más cuando varios equipos trabajan en distintos componentes de un mismo sistema. Algunas medidas que pueden ayudar a su equipo y a usted son:
- Los comités de cambios integrados por especialistas en la materia, además de responsables de gestión, pueden ayudarle a identificar dependencias entre distintos equipos antes de realizar los cambios.
- Las arquitecturas débilmente acopladas basadas en SOA y microservicios reducen las dependencias y el esfuerzo de comunicación.
- Los representantes técnicos de los equipos de DevOps deben identificar las dependencias y el orden de desarrollo y despliegue.
- Mantener la comunicación continua en plataformas de chat comunes para sincronizar los cambios y comprender y comprobar lo que han entendido los demás.
- Los cambios de mayor impacto y riesgo, como migraciones o cambios de infraestructura, exigen ensayos en entornos de prueba y medidas técnicas como mecanismos de conmutación por error y de reversión completa.
Las organizaciones DevOps de alto rendimiento se apoyan más en las revisiones entre pares y menos en las aprobaciones externas
Muchas organizaciones DevOps destacadas, entre ellas Amazon, Netflix, Etsy y GitHub, utilizan un proceso de revisión y despliegue mediante «pull requests». Así funciona:
- La desarrolladora crea una rama de desarrollo separada a partir del tronco. La rama no debe durar más de unos días laborables y debe tener un nombre claro y descriptivo, como «login-screen-v2». Trabaja en esa rama localmente en su estación de trabajo y registra periódicamente sus cambios en el control de versiones.
- Cuando considera que la rama de desarrollo está lista para fusionarse con el tronco, abre una «pull request» para solicitar una revisión.
- Tras recibir los comentarios y la aprobación de otras personas de su equipo de DevOps, fusiona su código con el tronco. Luego lo despliega en producción.
Para cambios delicados, como los esquemas de bases de datos o los cambios que puedan afectar a la seguridad de las aplicaciones, también puede enviar otras «pull requests» para recibir comentarios de especialistas de la organización, como administradores de bases de datos o especialistas en seguridad de la información.
Al revisar código, vuelva a aplicar el principio de los lotes pequeños. De lo contrario, la revisión tarda más y supone una gran carga para quienes revisan. Cuanto mayor es el cambio, más crece su riesgo de forma exponencial y menos fiable resulta la revisión. Si es demasiado grande y cuesta entenderlo, se puede pedir a la desarrolladora que lo divida en partes más pequeñas y comprensibles.
Todos los integrantes del equipo de DevOps, con independencia de su antigüedad o experiencia, deben pedir a alguien que revise sus cambios. Todos deben seguir el flujo de commits para detectar y resolver pronto los posibles conflictos, antes de que provoquen problemas mayores en la canalización o, peor aún, en un despliegue en producción.
La programación en pareja, por sí sola o combinada con el desarrollo guiado por pruebas (TDD), permite hacer revisiones entre pares mientras se escribe el código. En el segundo caso, una persona escribe el código de la aplicación y la otra, las pruebas automatizadas. Con el mismo tamaño de equipo y los mismos requisitos de proyecto, se ha medido y demostrado que la programación en pareja tarda un 15 % más, pero reduce un 85 % los errores de código. Por eso, es una práctica importante que su equipo de DevOps y usted deberían valorar.
También puede considerar las revisiones en las que una persona observa cómo trabaja otra, las notificaciones automáticas del flujo de cambios y las herramientas que facilitan revisar el código y mejorar su calidad.
CONCLUSIÓN
Haga que cada equipo de DevOps sea responsable de la calidad de sus propios entregables. Cree una cultura que valore las revisiones de código continuas y de calidad tanto como escribir código de calidad.
