¿Qué son los patrones de implementación?
Un patrón de implementación es una forma automatizada de implementar con facilidad características nuevas de la aplicación para los usuarios. Un patrón de implementación adecuado ayuda a minimizar el tiempo de inactividad. Algunos patrones también permiten implementar nuevas características de manera progresiva. De este modo, puede validar las características nuevas con usuarios concretos antes de que estas características estén disponibles para todos.
En esta sección, obtendrá información sobre algunos patrones de implementación comunes. También aprenderá cómo Azure App Service ayudará a implementar el patrón elegido por el equipo de Tailspin.
Reunión de la mañana
El equipo de Tailspin se siente bien. Su canalización ha acelerado su proceso. El equipo tiene un entorno de desarrollo en el que pueden integrar la aplicación web con una base de datos. Tim y Amita están encantados de tener pruebas automatizadas que simplifican sus trabajos. En general, ven menos retrasos y menos errores.
Pero, como siempre, hay un problema. Se unirá a la reunión del equipo, mientras Tim habla.
Tim: Es muy difícil contentar a todo el mundo. Irwin cree que se tarda demasiado tiempo en publicar nuevas características. No puedo hacer nada hasta que la dirección apruebe la versión y, en este momento, no hay ninguna manera sencilla de implementar las características después de que las hayan aprobado. El proceso no solo es largo, sino complejo. Es manual y hay tiempo de inactividad. Todo el proceso puede tardar cinco días. Sé que es demasiado tiempo, ¿pero qué se supone que debo hacer? Quizás si me tomo otro café me llegue la inspiración.
Andy: El café es esencial para la resolución eficaz de los problemas, sin duda.
Creo que la solución que necesitamos es un buen patrón de implementación. Un patrón de implementación es una forma automatizada de realizar la transición. Es cómo trasladamos el software de la fase de preproducción final a la de producción en vivo.
La selección del patrón adecuado será muy útil, sin duda, y podría minimizar el tiempo de inactividad. Otra ventaja de un patrón de implementación es que nos ofrece la oportunidad de ejecutar pruebas que realmente deberían suceder en producción.
Andy comienza a escribir en la pizarra.
Estas son las posibilidades que debemos tener en cuenta:
- Implementación azul-verde
- Versiones de valor controlado
- Activación/desactivación de funcionalidad
- Inicios oscuros
- Pruebas A/B
- Implementación de exposición progresiva
Ahora se analizará brevemente cada patrón.
Implementaciones azul-verde
Una implementación azul-verde reduce el riesgo y el tiempo de inactividad mediante la ejecución de dos entornos idénticos. Estos entornos se denominan azul y verde. En un momento dado, solo uno de los entornos está activo. Una implementación azul-verde implica normalmente un enrutador o un equilibrador de carga que ayuda a controlar el flujo de tráfico.
Imagine que el entorno azul es el activo. A medida que se prepara una versión nueva, las pruebas finales se realizan en el entorno verde. Una vez que el software funcione en el entorno verde, se cambia el enrutador para que todas las solicitudes entrantes vayan a este entorno.
La implementación azul-verde también ofrece una forma rápida de realizar una reversión. Si se produce algún error en el entorno verde, simplemente se vuelve a cambiar el enrutador al entorno azul.
Versiones de valor controlado
Una versión de valor controlado es una forma de identificar posibles problemas en una fase inicial sin exponer a todos los usuarios a la incidencia. La idea es exponer una característica nueva a un pequeño subconjunto de usuarios antes de ponerla a disposición de todo el mundo.
En una versión de valor controlado, se supervisa lo que sucede al publicar la característica. Si la versión tiene problemas, se aplica una corrección. Una vez que se sabe que la versión de valor controlado es estable, se mueve al entorno de producción real.
Activación/desactivación de funcionalidad
Use la activación/desactivación de funcionalidad para "darle a un interruptor" en tiempo de ejecución. Se puede implementar software nuevo sin exponer ninguna otra funcionalidad nueva o modificada a los usuarios.
En este patrón de implementación, Mara y yo creamos características detrás de un comando de alternancia. Cuando hay una versión, la característica se "desactiva" para que no afecte al software de producción. En función de cómo se configure la alternancia, podemos "subir" el interruptor y exponer la característica como queramos.
Por ejemplo, primero podríamos exponer la característica a unos cuantos usuarios para ver cómo reaccionan. Ese conjunto aleatorio de usuarios verá la característica. O bien, podríamos activar la característica para todos.
Pero este modelo de implementación podría beneficiarnos a Mara y a mí más que al resto. Una gran ventaja del patrón de activación/desactivación de funcionalidad es que nos ayuda a evitar demasiadas ramas. La combinación de ramas puede ser complicada.
Inicios oscuros
Un inicio oscuro es similar a una versión de valor controlado o a la activación/desactivación de funcionalidad. En lugar de exponer una característica nueva para todos los usuarios, en un inicio oscuro se publica para un pequeño conjunto de ellos.
Esos usuarios no saben que están probando la característica para nosotros. Ni siquiera les anunciamos la nueva característica. Por eso se llama "inicio oscuro". El software se publica de forma gradual o discreta para los usuarios, de modo que podamos obtener comentarios y poder probar el rendimiento.
Pruebas A/B
Las pruebas A/B comparan dos versiones de una página web o una aplicación para determinar cuál funciona mejor. Las pruebas A/B son como un experimento clásico.
En las pruebas A/B, se muestran dos o más variaciones de una página de forma aleatoria a los usuarios. Después, usamos el análisis estadístico para decidir qué variación funciona mejor para nuestros objetivos.
Implementación de exposición progresiva
La implementación de exposición progresiva se denomina a veces implementación basada en anillo. Es otra manera de limitar cómo afectan los cambios a los usuarios, a la vez que nos aseguramos de que esos cambios sean válidos en un entorno de producción.
Los anillos son básicamente una extensión de la fase de valor controlado. Las versiones de valor controlado se publican en una fase para medir el efecto. La adición de otro anillo es esencialmente el mismo concepto.
En una implementación basada en anillo, los cambios se implementan primero para los clientes tolerantes al riesgo. Después, la implementación se realiza de forma progresiva en un conjunto mayor de clientes.
Implementación azul-verde
Andy mira a Tim.
Andy: Es mucho, ya lo sé. ¿Quieres tomarte algo de tiempo para pensártelo? O tu y yo podríamos...
Tim: Azul-verde.
Todos se ríen.
Mara: ¿Son los efectos del café?
Tim: La activación/desactivación de funcionalidad implica un cambio en cómo trabajáis Andy y tú. Cada cosa a su tiempo. Los métodos que exponen una característica de forma gradual necesitan análisis estadísticos o alternancias de características.
Una implementación azul-verde es algo que puedo controlar. El cambio de un enrutador es sencillo. Es fácil y parece seguro. Y, en una implementación azul-verde, la dirección tiene un entorno que puede evaluar. Cuando den el visto bueno, podemos cambiar fácilmente. Empecemos por eso.
Por tanto, la pregunta es cómo realizar una implementación azul-verde en nuestra canalización.
¿Qué son las ranuras de implementación?
Andy: Como usamos Azure App Service, podemos aprovechar las ranuras de implementación. Las ranuras de implementación son aplicaciones en ejecución que tienen sus propios nombres de host.
Ya sé que todavía no estamos preparados para implementar el sitio web Space Game en producción como parte de la canalización automatizada. Pero como prueba, podemos agregar una ranura de implementación a nuestro entorno de ensayo.
En lugar de configurar un equilibrador de carga o un enrutador, podemos agregar una segunda ranura a la instancia de App Service que usamos en nuestro entorno de ensayo existente. Podemos llamar a la ranura primaria azul y a la verde.
De este modo, podemos implementar nuevas características sin tiempo de inactividad. Intercambiamos una aplicación y su configuración entre las dos ranuras de implementación. Básicamente, lo que hacemos es intercambiar las direcciones IP de las dos ranuras.
Tim: ¡Me gusta! Esta variación de una implementación azul-verde se podría denominar implementación sin tiempo de inactividad.
Andy: ¡Excelente! Tim y yo trabajaremos en la implementación de este patrón de implementación. Podemos reunirnos más adelante para ver los resultados.
Recomendaciones para el uso de marcas de características
Las marcas de características han sido uno de los métodos de cadencia de versiones que el equipo ha considerado. El equipo ha decidido no usarlas, pero a muchas personas les han sido útiles. En esta sección se proporciona más información sobre las marcas de características.
Las marcas de características, en ocasiones denominadas activación/desactivación de funcionalidad, le permiten cambiar el funcionamiento de un sistema sin modificar el código. Estas marcas permiten insertar código nuevo en la rama de desarrollo central y hacer que se implemente pero que no sea necesariamente funcional. Las marcas se implementan normalmente como el valor de variables que controlan lógica condicional.
Imagine que el equipo trabaja en la rama de desarrollo central de una aplicación de banco. Ha decidido realizar todo el trabajo en la rama principal para evitar complejas operaciones de combinación más adelante. Pero se enfrenta a un problema. Va a cambiar sustancialmente el cálculo de los intereses y los usuarios dependen de ese código a diario. Lo que es peor, los cambios tardarán semanas en completarse. No puede dejar el código principal interrumpido durante mucho tiempo.
En este escenario, una marca de características podría ser una buena solución. Puede cambiar el código para que los usuarios que no tengan establecida la marca de características puedan seguir usando el código de cálculo de interés original. Mientras tanto, el equipo tiene establecida la marca de características, por lo que puede ver el código que cambian.
Otro tipo de marca de característica es una marca de versión. Imagine que, después de completar el trabajo en el código de cálculo de intereses, quiere probarlo antes de publicarlo. Tiene un grupo de usuarios que están bien preparados para trabajar con código nuevo y los problemas que puedan surgir. Les permitirá probar la característica en primer lugar. Cambia la configuración para que también tengan establecida la marca de características y puedan probar el código nuevo. Si se produce algún problema, puede deshabilitar rápidamente la marca.