Cómo Microsoft ofrece software con DevOps

Microsoft tiene décadas de experiencia ofreciendo 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 evolucionado con el tiempo. 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 responsable que posean, prueben y entreguen características.
• Cambie 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 normales en producción.

Temiendo la falta de estabilidad del producto con sprints cortos, algunos equipos habían compensado con períodos de estabilización al final de sus ciclos de sprint. Los ingenieros querían enviar tantas características como sea posible durante el sprint, por lo que incurrían en deudas de prueba que tenían que pagar durante la estabilización. Los equipos que administraban su deuda durante el sprint tenían que apoyar a los equipos que construían deuda. Los costos adicionales se manifiestan a través de los canales de distribución y en el proceso de 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 posponer el trabajo de mantenimiento clave hasta el período de estabilización, los equipos que acumularon deuda tenían que dedicar el siguiente sprint a ponerse al día con 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 comprueban y merecen la pena el costo de la implementación.

Automatización completa de canalizaciones

La mayoría de los equipos pueden lograr inmediatamente una mejora automatizando completamente las canalizaciones desde el repositorio de código hasta la producción. La automatización incluye canalizaciones de lanzamiento con integración continua (CI), pruebas automatizadas, así como entrega continua (CD).

Es posible que los equipos eviten desplegar porque es complicado, pero cuanto menos frecuentemente lo hagan, más difícil será. Cuanto más tiempo entre las 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 implementando con frecuencia. Esta idea podría parecer obvia en la visión posterior, pero en el momento puede parecer contraintuito. 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 confiables.

Uso de herramientas internas

Microsoft usa el sistema de administración de versiones que compilan y los 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 desactivarí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 está en seguimiento. 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 razonablemente los equipos y las personas 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 planes para factores como el control de versiones, independientemente de los servicios en conjunto que dependen del microservicio.

Trabajo principal

Los ingenieros solían trabajar en ramas independientes. La combinación de deudas en cada rama creció hasta que el ingeniero intentó integrar su rama en la rama principal. Cuantos más equipos e ingenieros haya habido, mayor será 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 ahora trabajan en la rama principal. Una gran razón para pasar a Git fue la ramificación ligera que ofrece. La ventaja de la ingeniería interna fue eliminar la jerarquía de ramas profundas y sus residuos. Todo el tiempo que solía dedicarse a la integración ahora se dedica a la entrega.

Uso de marcas de características

Algunas características no están completamente finalizadas para una implementación de sprint, pero todavía pueden beneficiarse de las pruebas en producción. Teams puede 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 arriesgar problemas con la base de usuarios general y pueden ayudar a los equipos a determinar si y cómo completar la característica.

Pruebas en producción

Desplazar las pruebas hacia la producción ayuda a garantizar que las pruebas de preproducción sean válidas y que los entornos de producción, en constante cambio, estén listos para manejar las implementaciones.

Pruebas de instrumentos 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 qué agregar a continuación.

Probar patrones de resistencia

Un riesgo para implementaciones complejas es 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.

Elección de 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 falten nada. Pero esto puede provocar omitir o desconfiar del valor de las métricas que no satisfacen una necesidad específica. En su lugar, los equipos de Microsoft tardan tiempo en determinar los datos que necesitan para medir el éxito. Teams puede 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 para medir 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 proyecto a proyecto, 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 cómo están haciendo en salud, negocio, escenarios y telemetría de clientes. Las organizaciones describen las métricas con ejecutivos y con sus equipos.

Los equipos de toda la organización examinan las métricas de usuarios activos para determinar el valor de sus características. Los equipos no solo envían características, pero miran si las personas las usan y cómo las usan. Los equipos usan estas métricas para ajustar los pendientes y determinar si las funcionalidades necesitan más trabajo para cumplir con los objetivos.

Directrices de entrega

• Nunca es un camino recto para llegar de A a B; tampoco B 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 evoluciona sus prácticas de DevOps mediante la creación de la experiencia y el ajuste para satisfacer las necesidades cambiantes.
• La clave es centrarse en entregar valor, tanto a los usuarios finales como al propio proceso de entrega.