Ahora iremos a Azure DevOps, Pipelines -> Releases. Seleccionamos «New release pipeline» y del listado que aparece elegimos el «Empty job».
Primero de todo asignaremos a qué build irá vinculada esa definición de release desde «Add an artifact»:
En «Source» seleccionamos la definición de build que queremos usar, en «Default version» usaremos «Latest» y pulsamos «Add».
El siguiente paso es definir la Task con la extensión de release para Dynamics. Pulsamos en la pestaña Tasks y en el botón «+». Nos aparecerá una lista y buscaremos «Dynamics 365 Unified Operations Tools»:
Si no hemos añadido la extensión previamente lo podemos hacer desde esta misma pantalla. Para poderla añadir el usuario con el que estemos creando la release tiene que ser administrador de la cuenta de Azure DevOps en la que esté el proyecto, no es suficiente con que lo sea del proyecto.
Una vez añadida la tarea tenemos que rellenar una serie de parámetros:
¡Después de esperar mucho por fin ha llegado! Si ya tienes esto configurado para un entorno normal puedes cambiar a la nueva versión de la tarea sin problemas.
Despliegue de DP en Azure DevOps
La nueva versión 1 de la task funciona para ambos tipos de entornos: los gestionados por Microsoft (entornos normales) y los self-service. La versión 0 de la tarea es la vieja y solo funcionará para entornos normales. Puedes cambiar a la versión 1 en todas tus releases sin problemas.
¿Qué es diferente en la versión 1 de la task? Pues seguramente mucho trabajo por detrás que no vemos para que soporte los entornos self-service, pero a nivel de interfaz sólo vemos un nuevo campo llamado «Name for the update«.
Campo Name for the update en la task
Este campo se necesita sólo para entornos self-service, se ignorará en los normales, y corresponde al campo con el mismo nombre que aparece en LCS cuando queremos actualizar un entorno sandbox:
Name for this update en LCS
El valor por defecto de este campo es $(Release.ReleaseName), que es el nombre de la release, pero lo podemos cambiar. Por ejemplo yo uso un patrón del tipo PREFIJO RAMA $(Build.BuildNumber) para tener el mismo nombre que en la build y poder identificar más rápido qué vamos a desplegar en produción.
Y ya está, ya podemos sentarnos y relajarnos mientras nuestros entornos de test se actualizan gracias a los beneficios del CI/CD.