Resumen
En este módulo, definió un patrón de implementación como una manera automatizada de implementar sin problemas nuevas características de aplicación para los usuarios. Un buen patrón de implementación puede ayudarle a minimizar el tiempo de inactividad. También puede permitirle implementar nuevas características progresivamente a los usuarios.
Puede elegir entre varios patrones de implementación. El patrón de implementación que elija depende de los motivos de la implementación y los recursos. ¿Tiene evaluadores de valor controlado? ¿Usará un inicio oscuro y elegirá evaluadores que no sepan que lo son? Si tiene un conjunto de evaluadores de confianza que aumenta progresivamente de un conjunto pequeño a un conjunto mayor, puede elegir una implementación de exposición progresiva. O bien, si quiere saber si una versión funciona mejor que otra, puede elegir pruebas A/B.
El equipo de Tailspin eligió implementar el patrón de implementación azul-verde mediante ranuras de implementación en Azure App Service. Las ranuras de implementación son aplicaciones activas que tienen sus propios nombres de host. El equipo puede intercambiar dos ranuras de implementación. Al intercambiar, pueden promover cambios en la producción de forma instantánea. Aunque el equipo no está listo para lanzar su sitio web al público, han demostrado que pueden obtener nuevas características a sus usuarios sin incurrir en tiempo de inactividad.
Como ventaja, en este módulo también ha aprendido a poner al día un cambio no deseado mediante la reversión de una confirmación de Git y, después, el envío del cambio revertido por medio de la canalización.
¿Cómo trabaja el equipo?
Al inicio del recorrido de DevOps del equipo, Mara realizó un ejercicio de mapeo de flujo de valor que ayudó al equipo a analizar su proceso de ciclo de lanzamiento actual.
Recuerde que la relación de actividad, o la eficacia, es el tiempo de proceso dividido por tiempo total de tiempo de espera:
$${Ratio\ de\ actividad\ =\ }{\dfrac{Tiempo\ de\ proceso}{Tiempo\ total\ de\ entrega}}$$
El equipo web de Tailspin usó inicialmente esta métrica para determinar que eran un 23 % eficientes.
El equipo redujo primero algunas ineficiencias cuando implementaron la integración continua (CI). Al aplicar la entrega continua (CD), ahora han reducido aún más las ineficiencias.
En las rutas de aprendizaje anteriores, el equipo redujo:
El tiempo necesario para configurar el control de código fuente para las nuevas características. El tiempo requerido pasó de tres días a cero días.
El equipo ha logrado esta mejora pasando del control de código fuente centralizado a Git, una forma de control de código fuente distribuido. Al usar el control de código fuente distribuido, no es necesario esperar a que se desbloqueen los archivos.
El tiempo necesario para entregar código a Amita, el evaluador. El tiempo requerido pasó de dos días a cero días.
El equipo ha logrado esta mejora moviendo su proceso de compilación a Azure Pipelines. Azure Pipelines notifica automáticamente a Amita cuando hay disponible una compilación. Los desarrolladores ya no necesitan actualizar la hoja de cálculo de Amita para notificarla.
El tiempo que tarda Amita en probar las nuevas características. El tiempo requerido pasó de tres días a un día.
El equipo ha logrado esta mejora mediante la prueba unitaria de su código. Ejecutan pruebas unitarias cada vez que un cambio se mueve a través de la canalización de compilación, por lo que a Amita les llegan menos errores y regresiones. La carga de trabajo reducida significa que Amita puede completar cada prueba manual más rápido.
La canalización de versión que ha creado junto al equipo en esta ruta ha permitido reducir lo siguiente:
El tiempo necesario para llevar la compilación a la fase de Prueba. El tiempo requerido pasó de tres días a un día.
El equipo ha logrado esto mediante un desencadenador programado para realizar la implementación en Prueba todos los días a las 3:00.
El tiempo necesario para llevar la compilación probaba a la fase de Ensayo. El tiempo requerido pasó de dos días a cero días.
El equipo ha logrado esta mejora agregando pruebas de UI de Selenium, una forma de prueba funcional, a la fase de Test. Estas pruebas automatizadas son mucho más rápidas que las versiones manuales.
El tiempo que se tarda en activar la compilación aprobada desde la fase de Ensayo. El tiempo necesario pasó de un día a menos de un día.
El equipo ha logrado esta mejora agregando comprobaciones de aprobación manuales a la canalización. Cuando la dirección dé el visto bueno, Tim puede liberar los cambios de Ensayo a la fase activa.
Estos cambios reducen el tiempo de ejecución total de 22 días a 10 días. Cuando se sustituyen estos números por la ecuación:
$${Ratio\ de\ actividad\ =\ }{\dfrac{5\ días}{10\ días}}{ = 0,50}$$
Multiplique el resultado en un 100 % y obtenemos una reducción del 50 %.
Aunque siempre hay espacio para mejorar, este cambio es una victoria para el equipo. No solo los clientes obtienen valor más rápidamente, el equipo de Tailspin ahora pasa menos tiempo esperando y más tiempo haciendo lo que más les gusta: ofrecer características que saben que a sus clientes les encantará.
Aprende más
Usa estos recursos adicionales para obtener más información sobre App Service, slots de implementación y revertir cambios.