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».
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«.
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:
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.