Planificar despliegues sin tiempo de inactividad con Azure AppServices y Azure DevOps

Introducción

En algún momento del ciclo de vida de cualquier aplicación web, la misma tendrá que ser actualizada por algún motivo: puede ser por cambios en los requerimientos de negocio, rebranding, corrección de errores, adopción de nuevas versiones de librerías de las cuales depende, etc.

Si todos nuestros usuarios están en la misma zona horaria, es fácil identificar una ventana de tiempo en la que llevar adelante la manutención offline, aplicar los cambios requeridos y volver a conectarla sin afectar la operativa.

Sin embargo, cuando nuestra aplicación tiene usuarios en diferentes zonas horarias, llevar la aplicación offline puede no ser una opción.

Aquí es donde se nos solicitará hacer un despliegue con cero tiempo de inactividad.

El proceso para llevar adelante un despliegue con cero tiempo de inactividad puede ser resumido de esta manera:

Definir diferentes slots para desplegar en Azure

Cuando creamos un App Service en Azure, podemos especificar distintos slots (espacios) a ser desplegados. Estos espacios son instancias aisladas de nuestra aplicación, con su configuración propia y URL único.

Una vez definido al menos un espacio, el espacio por defecto será etiquetado como Producción.

Para más información dirigirse a:  https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots

Identificar los cambios necesarios

El siguiente paso que necesitamos realizar es identificar exactamente qué cambios necesitan ser aplicados al ambiente de producción para actualizar la aplicación exitosamente.

¿Necesitamos actualizar el esquema de base de datos?, ¿Necesitamos cambiar la ubicación desde donde la aplicación está leyendo un archivo?

¿Hay otros cambios en los recursos externos siendo utilizados por la aplicación?

Esto es muy importante para un despliegue exitoso. Si todos los cambios relacionados con recursos externos son ubicaciones de donde leer archivos, siempre que el esquema de esos archivos continúe incambiado, no habrá que realizar pasos adicionales mas allá de actualizar los ajustes a las rutas de los archivos.

Ahora, si necesitamos actualizar el esquema de base de datos, tendremos que asegurarnos de que el código en la aplicación actualmente desplegado es enteramente compatible con el esquema de base de datos actualizado.

Dado que el código ya existente debería poder utilizar la base de datos exactamente de la misma manera que antes de las actualizaciones del esquema, las siguientes consideraciones deberían ser tenidas en cuenta dependiendo del cambio que necesitemos aplicar:

¿Necesitamos agregar más columnas a una tabla?

Antes de desplegar el nuevo código de aplicación:

• La nueva columna deberá permitir valores nulos o proveer un valor por defecto.
• La lectura de la tabla desde el stored procedures deberá listar las columnas de la tabla en vez de utilizar expresiones como SELECT * FROM… Esto es ya que el código existente debería recibir exactamente los mismos resultados que cuando lee de la tabla actualizada.

¿Necesitamos renombrar una columna en una tabla?

Antes de desplegar el nuevo código de aplicación:

• Debemos crear una nueva columna que contenga el nuevo nombre.
• Para cada entrada, debemos especificar que el valor de la nueva columna sea el mismo que el de la columna ya existente.
• El procedimiento de almacenaje que inserte o actualice entradas en la tabla deberá especificar el mismo valor para ambas columnas.

Luego de desplegar el nuevo código de aplicación:

• El procedimiento de almacenaje que inserte o actualice entradas en la tabla deberá tener únicamente el valor de la nueva columna.
• La columna anterior puede ser eliminada.

¿Necesitamos borrar una columna de una tabla?

Antes de desplegar el nuevo código de aplicación:

• El procedimiento de almacenaje que inserte o actualice entradas en la tabla no debería colocar el valor a la columna.
• El procedimiento de almacenaje que lea de la tabla deberá devolver un valor por defecto para la columna.
• La columna anterior puede ser eliminada.

Antes de desplegar el nuevo código de aplicación:

• El procedimiento de almacenaje que lee de la tabla ya no deberá devolver un valor para la columna.

¿Necesitamos cambiar la firma de un procedimiento de almacenaje?

• Si el cambio incluye adicionar o eliminar parámetros, devolver diferentes sets de columnas (o incluso un set de resultados adicional), deberíamos considerarla como un nuevo procedimiento de almacenaje. Deberá tener ya sea un nombre totalmente nuevo, o podría mantener el nombre anterior como parte del nuevo siempre y cuando incluyamos un número de versión. Por ejemplo:  “InsertCustomer_v2”.
• Si el cambio solo modifica el comportamiento interno del procedimiento, sin cambiar sus parámetros o estructura de resultados, el procedimiento existente podrá ser actualizado sin la necesidad de sumar pasos adicionales.

¿Necesitamos borrar un procedimiento de almacenaje?

• El procedimiento de almacenaje deberá ser eliminada una vez que el nuevo código de aplicación es desplegado.

Utilizar intercambio de espacios en Azure DevOps

Azure DevOps nos permite intercambiar espacios en nuestro pipeline de lanzamientos. Esto significa que podemos tener por ejemplo un espacio llamado “Staging” y hacer un intercambio entre los espacios “Staging” y “Producción” desde una tarea en Azure DevOps.

Haciendo un intercambio de espacios con “Producción” como objetivo nos asegura que “Producción” no tendrá tiempo de inactividad.

Para hacer un intercambio de espacios en nuestro pipeline de lanzamientos, solo necesitamos agregar una tarea a la etapa que representa nuestro entorno de producción:

Para más información sobre qué sucede exactamente durante un intercambio de espacios diríjase a https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#AboutConfiguration

Hay dos consideraciones importantes cuando desplegamos mediante un intercambio de espacios:

• Si la aplicación web tiene alguna entrada en el archivo appsettings.json or web.config que necesitemos cambiar, deberíamos cambiar los valores de ajustes a “Producción” mientras desplegamos a la fuente originaria del espacio (en este ejemplo “Staging”). No podemos hacer una transformación en la configuración de archivos mientras intercambiamos espacios.
• Dado que el espacio original para el intercambio requiere tener la misma configuración que producción, se recomienda tener al menos un espacio adicional que nos permita testear cambios antes de que sean desplegados a producción. Estos espacios adicionales pueden tener valores totalmente diferentes en el archivo appsettings.json or web.config, permitiéndonos configurar ambientes separados para testear cada cambio con seguridad sin afectar producción.

Una vez completados los pasos descriptos hasta ahora, los diferentes espacios para desplegar en nuestro App Service serán mostrados en el portal de Azure de esta manera:

Se recomienda para nuestro pipeline de release tener configuradas distintas etapas a ser desplegadas únicamente despúes que la etapa previa fué desplegada con éxito.

También es recomendable pre-configurar las aprobaciones de despliegues en cada etapa, especialmente en producción. Esto nos permitirá testear la aplicación web con las mismas configuraciones que en producción y así poder identificar errores que puedan estar sucediendo en esa configuración específica antes de que afecte al usuario final.

Si tenemos integración o testing end-to-end en nuestro proyecto, también es una buena idea hacer que el pipeline de releases los corra y sólo despliegue a producción una vez que todos los tests hayan pasado.

Las etapas en nuestro pipeline de releases se verían así:

Conclusión

Planificar un despliegue con cero tiempo de inactividad no es tarea trivial. Una vez identificamos la necesidad del mismo, el planning idealmente debería comenzar durante la etapa temprana del desarrollo de cambios que queramos incluir en el mismo.

Mayormente porque parte de los pasos mencionados arriba incluyen usar nuevos nombres para dependencias externas ya existentes (como ser el procedimiento de almacenaje) y realizar varios cambios a nuestro ambiente Azure y al pipeline de releases de Azure DevOps.