Resumen

  • 3 minutos

En este módulo ha definido un patrón de implementación como una forma automatizada de implementar con facilidad características nuevas de la 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 de manera progresiva para los usuarios.

Puede elegir entre varios patrones de implementación. El que elija dependerá de los motivos de la implementación, así como de 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 desde un conjunto pequeño a otro mayor, podría elegir una implementación de exposición progresiva. O bien, si quiere saber si una versión se comporta mejor que otra, podría elegir pruebas A/B.

El equipo de Tailspin ha optado por 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 hacerlo, pueden promocionar los cambios en producción de forma instantánea. Aunque en el equipo no están listos para publicar su sitio web, han demostrado que pueden ofrecer nuevas características para 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 mide el equipo?

En el módulo Evaluación del proceso de desarrollo de software existente, Mara ha realizado un ejercicio de asignación de flujos y valores. El ejercicio ha ayudado al equipo a analizar el proceso de ciclo de versiones actual.

Recuerde que el coeficiente de actividad, o eficiencia, es el tiempo de proceso dividido por el plazo total:

$${Coeficiente \ de actividad\ =\ }{\dfrac{Tiempo de\ proceso}{Plazo\ total\}}$$

Inicialmente el equipo web de Tailspin ha usado esta métrica para determinar que su eficacia era del 23 %.

El equipo ha reducido en primer lugar algunas ineficiencias en la implementación de la integración continua (CI). Al aplicar la entrega continua (CD), ahora han reducido todavía más las ineficiencias.

En rutas de aprendizaje anteriores, el equipo ha reducido lo siguiente:

  • El tiempo necesario para configurar el control de código fuente para nuevas características. El tiempo necesario ha pasado de tres días a cero días.

    El equipo ha logrado esta mejora después de cambia de control de código fuente centralizado a Git, una forma de control de código fuente distribuido. Mediante el control de código fuente distribuido, no tienen que esperar a que se desbloqueen los archivos.

  • El tiempo necesario para entregar el código a Amita, la evaluadora. El tiempo necesario ha pasado de dos días a cero.

    El equipo ha logrado esta mejora mediante el traslado del proceso de compilación a Azure Pipelines. Azure Pipelines notifica automáticamente a Amita cuando hay una compilación disponible. Los desarrolladores ya no tienen que actualizar la hoja de cálculo de Amita para notificárselo.

  • El tiempo que tarda Amita en probar las características nuevas. El tiempo necesario ha pasado de tres días a un día.

    El equipo ha logrado esta mejora mediante la realización de pruebas unitarias en el código. Ejecutan pruebas unitarias cada vez que un cambio pasa por la canalización de compilación, de forma que Amita recibe menos errores y regresiones. La carga de trabajo reducida significa que Amita puede completar cada prueba manual de forma más rápida.

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 necesario ha pasado 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 necesario ha pasado de dos días a cero.

    El equipo ha logrado esta mejora mediante la adición de pruebas de interfaz de usuario de Selenium, una forma de pruebas funcionales, a la fase de Prueba. 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 ha pasado de un día a menos de un día.

    El equipo ha logrado esta mejora mediante la adición de 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 plazo total de 22 a 10 días. Cuando se sustituyen estos números en la ecuación:

$${Coeficiente\ de actividad\ =\ }{\dfrac{5\ días}{10\ días}}{ = 0,50}$$

Multiplique el resultado por 100 % y se obtiene una reducción del 50 %.

Aunque siempre hay espacio de mejora, este cambio es un triunfo para el equipo. No solo los clientes obtienen valor más rápidamente, sino que el equipo de Tailspin ahora dedica menos tiempo a esperar y más a lo que más les gusta: proporcionar características que saben que a sus clientes les van a encantar.

Saber más

Use estos recursos adicionales para obtener más información sobre App Service, las ranuras de implementación y la reversión de los cambios: