Como pasar variables entre la Build y la Release en Azure DevOps

El otro día, montando un pileline en Azure DevOps, me encontré con una situación en la que según un valor que se obtiene en tiempo de Buid, tenia que ejecutar o no, una tarea en tiempo de Release.

Actualmente (no se si en el futuro lo implementarán) no se pueden pasar variables entre la build y la release, así que tuve que utilizar un pequeño workarround muy sencillo:

Guardar el valor en un fichero que añado al artifact, que luego leeré en la Release.

Existe en el marketplace una tarea que a priori hace esto mismo. Yo no la he probado pero parece que funciona. Si puedes, úsala y ya lo tendrás resuelto:

Variable Tools for Azure DevOps Services

Pero si estas trabajando para una organización, en la que no controlas la instalación de extensiones y que además tiene mucha burocracia, has de pensar muy bien cada petición de instalar nuevas extensiones. Si este es tu caso, aquí te explico como hacerlo con PowerShell.

Lo primero que has de hacer es añadir una tarea de PowerShell script que se encargue de crear el fichero (en mi caso un JSON) y de guardarlo dentro de la carpeta de trabajo de la build.

El script es el siguiente:

$jsonFile = @{version = $(UsdDataVersion.RECORD_VALUE)}
$jsonFile | ConvertTo-Json | Out-File "$(Build.ArtifactStagingDirectory)/data_version.json"

La cosa ha de quedar así:

Luego, como siempre, añade la tarea de publicar el artefacto.

Ahora en la parte de la release, solo tenemos que leerlo con otro script de PowerShell y asignarlo a una variable de salida para poder usarlo en el resto de tareas:

$json = Get-Content '$(System.DefaultWorkingDirectory)/xxxx/drop/data_version.json' | ConvertFrom-Json
$versionActual = $json.version

Write-Output "##vso[task.setvariable variable=test;]$versionActual"
Write-Host ("Valor de la versión actual: {0}" -f $versionActual)

Ahora ya podemos usar la variable en el resto de tareas:

2 comentarios en «Como pasar variables entre la Build y la Release en Azure DevOps»

    1. Hola Luisa, las builds y las releases son procesos separados, primero se ejecuta uno y luego el otro. Otra cosa, es que dentro de la build puedes desplegar directamente, sin hacerlo en la release.
      Mírate este a ver si te ayuda:
      https://daniccardenas.com/integracion-continua-y-despliegue-automatizado-en-azure-con-azure-devops/
      También puedes suscribirte a mi canal de YouTube donde voy publicado videos al respecto y puede que te interese:
      https://www.youtube.com/channel/UCdbvQPXxZe-k9hfwx38SAHg
      –> suscríbete 🙂

Deja una respuesta

Tu dirección de correo electrónico no será publicada.