¡Después de esperar mucho por fin ha llegado! Si alguno de vuestros clientes tiene entornos self-service habréis estado haciendo esto a mano. Nosotros llevamos más de un año y medio con un cliente así, desde la preview privada, y hemos echado MUCHO de menos esto en Azure DevOps.
Toda la documentación está disponible en la página del marketplace para las herramientas de DevOps.
Puedes leer mi guía completa sobre Dynamics 365 y Azure DevOps aquí.
Si quieres saber más sobre los entornos self-service puedes leer estos posts:
- Entornos self-service: el futuro que ya está aquí!
- Un aviso sobre los entornos self-service: actualizar con cuidado
- Self-service y SSRS: activa la preview en PDF en tu VM de desarrollo
Configurar la release para un entorno self-service
Si ya tienes esto configurado para un entorno normal puedes cambiar a la nueva versión de la tarea sin problemas.
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.
