Aquí puedes leer mi guía completa sobre Dynamics 365 for Finance and Operations y Azure DevOps.

Ya he escrito unos cuantos posts sobre la ALM (Application Lifecycle Management) de desarrollo  para Dynamics 365 for Finance and Operations in the past:

• Dynamics 365 for Finance & Operations y Azure DevOps (parte I)
• Dynamics 365 for Finance & Operations y Azure DevOps (parte II)
• Configurar Release en Azure DevOps para Dynamics 365 for Finance and Operations
• Configurar las nuevas tareas de Azure DevOps para generar el paquete y versiones de modelos

La posibilidad de hacer CI/CD real es una de mis cosas favoritas de MSDyn365FO, pasar del «¿Qué control de código?» a «O usas control de código o muere» ha sido una maravilla. Nunca me cansaré de decirlo.

Además el post acaba con un extra bonus!

¡Más automatización!

Ya he explicado antes como automatizar las builds, crear builds de CI y crear las releases en Azure DevOps, así que de lo que quiero hablar en este post es de añadir un poco más de automatización.

Builds

En la definición de build vamos a la pestaña «Triggers» y activamos las builds programadas:

Esto va a lanzar una build automaticamente los días que quieras y a la hora que le digas. En el ejemplo se lanza todos los días entre semana a las 16.30h. Pero… ¿todos los días? No. El check «Only schedule builds if the source or pipeline has changed» hace que sólo se lance la build si ha habido cambios en el código, así que si un día no hay changesets nuevos no se lanza la build.

Releases

Builds listas, a ver qué podemos hacer con las releases:

La release de la imagen de arriba es la que se lanza automáticamente después de la build que he creado en el primer paso. Para esta release he añadido lo siguiente:

El disparador de CD está activo, lo que hace que cada vez que una build termina se ejecuta automáticamente. Sin necesidad de definir una programación horaria, pero también se podría hacer.

Como véis, la pantalla de la programación es exactamente igual que en las builds, incluso el check de cambios está ahí. Se pueden usar cualquiera de estas dos formas, CD o release programada, depende de las necesidades del proyecto o equipo.

Con estos dos pequeños pasos tenemos la estrategia de CI y CD completamente automatizada, y la actualización del entorno de UAT cada noche para tener los cambios hechos durante el día listos para testear, sin humanos de por medio!

Pero a mi me gusta un poco de toque humano

Si no te gusta no saber cuando se actualiza un entorno… bueno eso es IMPOSIBLE porque LCS te Spamea para que no te pierdas ni un despliegue. Pero si lo que no quieres es ser completamente reemplazado por robots puedes añadir aprobaciones a tu flujo de release:

Haciendo clic en el icono izquierdo de relámpago + persona puedes configurar los aprobadores, una persona o grupo (cosa que es muy práctica), y el tipo de aprobación (única o múltiple) y timeout. También recibirás un correo con un enlace al formulario de aprobación:

¡E incluso puedes posponer el despliegue! ¡Todo es fabuloso!

Extra bonus!

Un pequeño consejo. Imaginemos que tenemos esta release:

Esto actualizaría 3 entornos, pero también haría 3 subidas del Deployable Package a LCS. ¿No estaría bien poder hacer una única subida y que los despliegues se hicieran usando ese archivo? Sí, pero no podemos pasar el valor de la variable de salida del stage de subida a los demas stages 🙁 Eso desgraciadamente es así. Pero podemos hacer algo con un poco de ayuda de nuestro amigo Powershell!

Actualizar una variable en una release

Lo que necesitamos es crear una variable en la definición de release y poner su ámbito como «Release»:

Luego, por cada stage que tengamos, tenemos que activar este check en el agent job:

Luego explicaré por qué. Ahora sólo tenemos que actualizar esta variable una vez subido el DP a LCS. Añadimos un Powershell de tipo inline después del paso de la subida y hacemos esto:

# Populate & store value to update pipeline
$assetId= "$(GoldenUpload.FileAssetId)"
Write-Output ('##vso[task.setvariable variable=localAsset]{0}' -f $assetId)

#region variables
$ReleaseVariableName = 'axzfileid'
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID)  )
#endregion

#region Get Release Definition
Write-Host "URL: $releaseurl"
$Release = Invoke-RestMethod -Uri $releaseurl -Headers @{
    Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
#endregion

#region Output current Release Pipeline
#Write-Output ('Release Pipeline variables output: {0}' -f $($Release.variables | #ConvertTo-Json -Depth 10))
#endregion

#Update axzfileid with new value
$release.variables.($ReleaseVariableName).value = $assetId

#region update release pipeline
Write-Output ('Updating Release Definition')
$json = @($release) | ConvertTo-Json -Depth 99
$enc = [System.Text.Encoding]::UTF8
$json= $enc.GetBytes($json)
Invoke-RestMethod -Uri $releaseurl -Method Put -Body $json -ContentType "application/json" -Headers @{Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN" }
#endregion

Necesitamos cambiar lo siguiente:

• Línea 2: $assetId= «$(GoldenUpload.FileAssetId)». Cambiar $(GoldenUpload.FileAssetId) por tu variable de salida.
• Línea 6: $ReleaseVariableName = ‘axzfileid’. Cambiar axzfileid por tu variable de Release.

Y listos. Este script usa la API REST de Azure DevOps para actualizar el valor de la variable con el file id, y hemos activado el check del token de OAuth para no tener que autenticarnos con ningún usuario. Esto no es idea mía, lo he hecho gracias a este post del blog de Stefan Stranger’s.

Ahora en los stages de despliegue recuperamos el valor de la variable así:

No os olvidéis los ( ) o no funcionará!!!

Y con este pequeño cambio tenemos una release como esta:

Con una única subida del DP a LCS y múltiples despliegues usando el archivo subida en el primer stage. Y con aprobaciones, y retrasos y correos y todo!

Ahora la mala noticia

La mala noticia es que, de momento, en los entornos de tipo self-service no se puede automatizar el despliegue. Y obviamente en los entornos de producción tampoco se puede automatizar nada, esa parte sigue siendo 100% manual.