Cómo distribuye Microsoft el software con DevOps
Microsoft tiene décadas de experiencia entregando servicios altamente escalables a entornos de producción. A medida que los servicios y entornos de Microsoft se han ampliado, sus prácticas de entrega también han ido evolucionado. Muchos clientes de Microsoft también han adoptado y se benefician de estas prácticas de entrega eficientes. Los siguientes principios y procesos básicos de DevOps se pueden aplicar a cualquier esfuerzo moderno de entrega de software.
Para implementar procesos de entrega de DevOps, Microsoft adoptó las siguientes iniciativas:
- Centrar la mentalidad y la cadencia de la organización en la entrega.
- Formar equipos autónomos y responsables que posean, prueben y entreguen características.
- Desplazar a la derecha para probar y supervisar los sistemas en producción.
Centrarse en la entrega
El envío más rápido es una ventaja obvia que las organizaciones y los equipos pueden medir y apreciar fácilmente. La cadencia típica de DevOps implica ciclos de sprint cortos con implementaciones regulares en producción.
Temiendo la falta de estabilidad del producto con sprints cortos, algunos equipos lo habían compensado con períodos de estabilización al final de los ciclos de sprint. Los ingenieros querían enviar tantas características como fuera posible durante el sprint, por lo que incurrían en una deuda de pruebas que terminaban pagando durante la estabilización. Los equipos que administraban su deuda durante el sprint tenían que apoyar a los equipos que acumulaban deudas. Los costes adicionales se producían durante las canalizaciones de entrega y en producción.
La eliminación del período de estabilización mejoró rápidamente la forma en que los equipos administraban su deuda. En lugar de abandonar el trabajo de mantenimiento clave en el período de estabilización, los equipos que acumulaban deuda tenían que dedicar el siguiente sprint a recuperar sus objetivos de deuda. Los equipos aprendieron rápidamente a administrar su deuda de pruebas durante los sprints. Las características se entregan cuando se han probado y justifican el coste de la implementación.
Automatización completa de canalizaciones
Gran parte de las mejoras que pueden obtener los equipos inmediatamente es la automatización completa de las canalizaciones del repositorio de código a producción. La automatización incluye la liberación de canalizaciones con integración continua (CI), pruebas automatizadas y entrega continua (CD).
Los equipos podrían evitar la implementación porque es difícil, pero cuanto menor es la implementación, más difícil es. Cuanto más tiempo pasa entre implementaciones, más problemas se acumulan. Si el código no está actualizado, hay deuda de implementación.
Es más fácil trabajar en fragmentos más pequeños mediante la implementación frecuente. Esta idea podría parecer obvia a posteriori, pero en el momento puede parecer contraria a la lógica. Las implementaciones frecuentes también motivan a los equipos a priorizar la creación de herramientas y canalizaciones de implementación más eficaces y fiables.
Uso de herramientas internas
Microsoft usa el sistema de administración de versiones que compilan y lo envía a los clientes. Una sola inversión mejora la productividad del equipo y los productos de Microsoft. El uso de un sistema secundario reduciría el desarrollo y la velocidad de entrega.
Autonomía y responsabilidad del equipo
Ningún indicador clave de progreso (KPI) específico mide la productividad o el rendimiento del equipo, o si una característica va por buen camino. Los equipos deben poder administrar sus propios planes y trabajos pendientes, al tiempo que encuentran una manera de alinearse con los objetivos de la organización.
Es importante comunicarse directamente con los equipos para realizar un seguimiento del progreso. Las herramientas deben facilitar la comunicación, pero la conversación es la forma más transparente de comunicarse.
Priorizar características
Un objetivo importante es centrarse en la entrega de características. Las programaciones pueden evaluar cuánto pueden completar los equipos y las personas razonablemente durante un período de tiempo determinado, pero algunas características se entregarán antes y otras más tarde. Los equipos pueden priorizar el trabajo para que las características más importantes lleguen a producción.
Uso de microservicios
Los microservicios ofrecen diversas ventajas técnicas que mejoran y simplifican la entrega. Los microservicios también proporcionan límites naturales para la propiedad del equipo. Cuando un equipo tiene autonomía sobre la inversión en un microservicio, puede priorizar cómo implementar características y administrar la deuda. Los equipos pueden centrarse en los planes de factores como el control de versiones, independientemente de los servicios generales que dependen del microservicio.
Trabajo en la rama principal
Los ingenieros solían trabajar en ramas independientes. La deuda combinada de cada rama crecía hasta que el ingeniero intentaba integrar su rama en la rama principal. Cuantos más equipos e ingenieros había, mayor era la integración.
Para que la integración se produzca más rápido, de forma más continua y en fragmentos más pequeños, los ingenieros trabajan ahora en la rama principal. Una gran razón para pasar a Git era la bifuración ligera que ofrece Git. La ventaja para la ingeniería interna era eliminar la jerarquía de ramas profundas y sus residuos. Todo el tiempo que solía dedicarse a la integración ahora se vierte en la entrega.
Uso de marcas de características
Algunas características no están completamente finalizadas para una implementación de sprint, pero pueden beneficiarse igualmente de las pruebas en producción. Los equipos pueden combinar e implementar este código con marcas de características para activar la característica para usuarios específicos, como el equipo de desarrollo o un pequeño segmento de usuarios pioneros. Las marcas de características controlan la exposición sin arriesgarse a problemas con la base de usuarios general y pueden ayudar a los equipos a determinar si hay que completar la característica y cómo hacerlo.
Pruebas en producción
El desplazamiento de pruebas a la derecha en producción ayuda a garantizar que las pruebas de preproducción sean válidas y que los entornos de producción siempre cambiantes estén listos para controlar las implementaciones.
Instrumentar pruebas y métricas
Independientemente de dónde se implemente una aplicación, es importante instrumentar todo. La instrumentación no solo ayuda a identificar y corregir problemas, sino que puede proporcionar una investigación valiosa sobre el uso y sobre qué agregar a continuación.
Patrones de resistencia de pruebas
Un riesgo para las implementaciones complejas son los errores en cascada, en los que un error de componente hace que se produzca un error en los componentes dependientes, etc. hasta que se descompone todo el sistema. Es importante comprender dónde están los puntos únicos de error (SPOF) y cómo se mitigan, y probar los procesos de mitigación, especialmente en producción.
Elegir las métricas adecuadas
El diseño de métricas puede ser difícil. Un error común es incluir demasiadas métricas para evitar que falte nada. Pero esto puede provocar omisiones o desconfianza en el valor de las métricas que no satisfacen una necesidad específica. En su lugar, los equipos de Microsoft dedican tiempo a determinar los datos que necesitan para medir el éxito. Los equipos pueden agregar o cambiar métricas, pero comprender el propósito desde el principio facilita ese proceso.
Además de la base de una métrica, los equipos consideran lo que necesitan que mida la métrica. Por ejemplo, la velocidad o aceleración de las ganancias del usuario podría ser una métrica más útil que el número total de usuarios. Las métricas varían de un proyecto a otro, pero las más útiles son las que tienen el potencial de impulsar las decisiones empresariales.
Uso de métricas para guiar el trabajo
Microsoft incluye métricas con revisiones en los niveles de liderazgo más altos. Cada seis semanas, las organizaciones presentan su situación en cuanto a telemetría de salud, empresa, escenarios y clientes. Las organizaciones discuten las métricas con los ejecutivos y sus equipos.
Los equipos de toda la organización examinan las métricas de usuario en curso para determinar el significado de sus características. Los equipos no solo envían características, sino que miran si las personas las usan y cómo las usan. Los equipos usan estas métricas para ajustar los trabajos pendientes y determinar si las características necesitan más trabajo para cumplir los objetivos.
Directrices de entrega
- Ir de A a B no es nunca una línea recta, y B no es el final.
- Siempre habrá retrocesos y errores.
- Vea los retrocesos como oportunidades de aprendizaje para cambiar las tácticas para completar una parte determinada del proceso.
- Con el tiempo, cada equipo desarrolla sus prácticas de DevOps a partir de la experiencia y ajustando para responder a necesidades cambiantes.
- La clave es centrarse en entregar valor, tanto a los usuarios finales como al propio proceso de entrega.