15.3 Generando el Release en Azure Pipelines al App Service de Azure

Una vez que generamos los artifacts vamos a crear nuestro release, en este ejemplo creare un release automático, en el cual después del commit se instalará automáticamente en el AppService creado en la sección 12.1 Crear un App Service en Azure.

Entra a Azure DevOps, selecciona la opción Pipelines, luego Releases.
Da clic en el botón New Pipeline

3. Del lado izquierdo se muestran los pasos de tu release, y del lado derecho se muestran sugerencias para crear tu release, elige la opción Azure App Service deployment y da clic en Apply.

4. En Stage name escribe un nombre descriptivo, en este ejemplo será Deploy to Azure y selecciona quien es el dueño de este paso, selecciona al usuario encargado del deploy. Da clic en el botón cerrar(X).

Si todo es correcto queda de la siguiente manera:

4. Da clic en Add an artifact para seleccionar nuestros artifacts.

5. Selecciona lo siguiente:

Source Type: Selecciona Build para utilizar los artifacts creado en el pipeline.
Project: Selecciona tu proyecto de Azure Devops en este caso es CaducaRest
Source (build pipeline): Selecciona tu pipeline. En mi caso se llama apis3445.CaducaRest
Default version: Selecciona Latest para seleccionar la última versión generada.
Source alias: Agrega un nombre para identificar el release, en mi caso será desarrollo.

6. Da clic en el link 1 job, 1 task para configurar el deploy.

Debido a que de momento Azure Pipelines no soporta correctamente la versión de .Net Core 3.1 voy a borrar el task generado por default para agregar otro que permite mas configuración.

7. Selecciona el task Deploy Azure App Service y da clic en el botón Remove.

Actualiza automáticamente tu base de datos.

Actualizando tu base de datos de MySQL en un hosting o servidor.

Si tienes tu base de datos en un servidor propio o en un hosting puedes utilizar la tarea MySQL database deploy.

Primero voy a agregar variables de tipo secret con los datos para conectarme a la base de datos de MySQL.

Selecciona el tab Variables y da clic en el botón + Add.

Agrega una variable para configurar la conexión a la base de datos. Da clic en el candado para mantenerlas secret. Un ejemplo del nombre de las variables puede ser el siguiente:

MySQLS: Contiene el nombre del servidor de la base de datos.
MySQLD: Contiene el nombre de la base de datos.
MySQLP: Contiene el password del usuario con acceso a modificar la base de datos.
MySQLU: Contiene el usuario con acceso a modificar la base de datos.

2. Regresa al tab Tasks, da clic en el botón + Agrega la tarea MySQL database deploy y da clic en Add.

Agrega los siguientes valores:

Display name: El nombre que se verá en tu task, en este caso será Actualizar BD.
Deploy MySQL using: Puedes seleccionar si deseas actualizar tu base de datos con un archivo script o tecleando directamente las sentencias para actualizar tu base de datos. Elige la opción MySQL Script File ya que ya tenemos generado el archivo.
MySQL Script: Selecciona el archivo que creaste en el pipeline. En este caso es: $(System.DefaultWorkingDirectory)/_apis3445.CaducaRest/Scripts/update_to_latest.sql
Host Name: Agrega la variable del servidor en mi caso es $(MySQLS).
Database Name: Agrega la variable con el nombre de la base de datos. $(MySQLD).
Mysql User Name: Agrega la variable con el nombre del usuario de la base de datos: $(MySQLU).
Password: Agrega la variable con el password: $(MySQLP).

Actualiza tu App Service de Linux.

Por último debes agregar un task para subir tu aplicación al App Service de Linux.

Da clic en el botón + para agregar una tarea Azure Web App.

2. Configura la tarea de la siguiente manera:

Diplay name: Es el nombre del paso en este caso es: Azure Web App Deploy: restcaduca.
Azure subscription: Selecciona la suscripción de Azure en donde creaste tu AppService y da clic en Authorize.

App type: Selecciona tu tipo de app, en mi caso como mi app service es linux, seleccionaré Web App on Linux.
App name: Selecciona el nombre de tu app en mi caso es restcaduca.
Package or folder: Selecciona el artifacto creado para linux: $(System.DefaultWorkingDirectory)/_apis3445.CaducaRest/restLinux/CaducaRest.zip
Runtime stack: Selecciona el runtime 3.1 (DOTNETCORE|3.1).

Da clic en Save y listo.

Actualiza automáticamente después del commit.

Para configurar que se ejecute automáticamente el release da clic en el símbolo de un rayo y selecciona la opción Enabled.

Actualiza en una fecha y hora.

También puedes programar el release para una fecha y hora en especial si das clic en la opción Schedule not set.

Selecciona la opción Enabled y por default te sugiere que se actualice de Lunes a Viernes a las 3:00 am.

Actualiza de forma manual.

Una vez configurado, cada vez que hagas un cambio al código se ejecuta el release, si deseas ejecutar un release de forma manual da clic en Create release.

Puedes configurar lo siguiente:

Stages: Puedes seleccionar uno de los pasos o todos los pasos que has configurado. En mi caso ya tengo el release con 2 pasos uno para el deploy y otro para testing.
Artifacts: Puedes seleccionar la versión de tu sistema que deseas instalar.
Release description: Agrega una descripción para el release.

Por último da clic en Create y se ejecutaran los pasos.

Puedes seleccionar el release y ver el avance paso a paso.

Al finalizar verás algo similar a lo siguiente:

En caso de ocurrir algún error llega un correo a la cuenta del usuario owner del release, con el detalle del error.

Después de terminar puedes entrar a tu sitio web.

Puedes ver la documentación oficial para configurar el release en Azure Devops aquí.

Agrega condiciones antes o después de cada paso.

Azure Dev Ops te permite agregar una variedad de condiciones antes o después de cada Stage algunos ejemplos son:

Seleccionar uno o mas miembros del equipo para que aprueben los artifacts antes de hacer el deploy.
Solo permitir release por medio de Pull Request y que los Pull Request sean aprobados por uno o mas miembros del equipo.
Asegurar que no tengas bugs, defectos o soportes activos o puedes por ejemplo filtrar para que estén terminadas ciertas tareas importantes
Puedes agregar tareas (Manual Intervention task) que deben ser completadas manualmente antes del release por ejemplo asegurarse por medio de un correo electrónico que el cliente apruebe la instalación de la nueva versión, o que se haya pagado por la actualización del sistema.
Deseas que un usuario manualmente cambie los parámetros o variables del pipeline.

Agregando condiciones para no desplegar si hay bugs que no están cerrados.

Para poder agregar una regla donde antes del release no debe existir ningún bug abierto en el sprint, es necesario primero crear el query con la regla que deseas.

Ve a la opción: Boards -> Queries. Da clic en New query.

2. Agrega los Filtros para filtar los bugs que se encuentran activos en el sprint actual con los siguientes filtros:

Work Item Type = Bug
And State <> Closed
And Iteratipon Path = @CurrentIteration y selecciona tu proyecto

Si le das clic en Run query se ejecutan los filtros y se ven los resultados, en mi caso no tengo ningún bug activo, por lo tanto no se muestran resultados.

3. Da clic en Save query, teclea el nombre por ejemplo Bugs Activos y en el Folder tiene que estar en Shared Queries para que sea utilizada en el release. Da clic en el botón OK.

4. Ve a Pipelines -> Releases en el área de Deploy selecciona tu Release y da clic en Edit.

5. Da clic en Pre-Deployment conditions el cual tiene el símbolo de una persona.

Habilita la opción Gates. Ir a Gates luego Enabled.

Da clic en el botón + Add y selecciona la opción Query work items.

6. Selecciona las siguientes opciones:

Query: selecciona la query que acabas de crear Bugs Activos .
Upper treshold: Es la cantidad máxima de resultados que debe regresar el query, en este caso es 0 porque no queremos ningún bug activo.

Da clic en Save y agrega algún comentario.

Agregando personas que autoricen el release.

Puedes agregar otra condición para por ejemplo seleccionar al usuario que apruebe o rechace los cambios, esto para el caso de tener un servidor de qa, algunos usuarios puedan revisar y aprobar la versión.

Selecciona Post-Deployment Conditions el icono de un usuario al final del stage de las pruebas.

2. Configura lo siguiente:

Post-deplyment: approvals Enabled
Timeout: Elije la cantidad máxima de días que tienen para revisar la versión.
Approval policies: selecciona esta opción si deseas que la persona que solicita el pull request no debe ser la amisma que la aprueba.