🥇Uso de variables en pipelines de Azure DevOps

Continuamos nuestra revisión de una herramienta maravillosa para el desarrollo bajo Windows и не только, Azure DevOps. На этот раз, намучавшись с переменными окружения, я решил вынести весь опыт в одну статью.

Empezando por el hecho de que tienen una sintaxis diferente para cada entorno de ejecución, terminando con la falta de una capacidad estándar para transferir variables de una etapa del proceso a otra.

Haré una reserva de que los ejemplos principales estarán en Release Pipelines, porque YAML aún no ha llegado allí y necesito la funcionalidad de muchas etapas y muchos artefactos. Esto, al parecer, está disponible en Pipelines normales, lo que prácticamente los iguala en funcionalidad. En Pipelines YAML, agregamos una pequeña información sobre herramientas gráfica a la vista de texto con parámetros que se pueden configurar. Es muy conveniente, no es necesario revisar la documentación de cada módulo. Pero describiré esto en el próximo artículo, pero por ahora aquí hay una imagen de la innovación en sí.

Almacenamiento y uso

Comencemos con el hecho de que tenemos variables predeterminadas en el sistema. Comienzan, según su origen, con las palabras Release, System, etc. La lista completa (que resulta que no) está disponible en documentación. Toda la esquizofrenia con sintaxis se ilustra con un ejemplo de la documentación siguiente. Una misma variable tiene tres representaciones, según donde la llamemos.

steps:
 - bash: echo This script could use $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "This is a script that could use $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Si configura una variable en el agente en el que se ejecuta la tarea, es $(System.AccessToken). Si desea usarlo dentro de un script de PowerShell en el mismo agente, ya será $env:SYSTEM_ACCESSTOKEN. Si usted, Dios no lo quiera, desea usar esta variable en algún host remoto usando la tarea PowerShell en las máquinas de destino, debe pasar esto a través de un argumento al script usando detener. Con bash es más simple, simplemente puedes pasarlo usando el argumento y la sintaxis $SYSTEM_ACCESSTOKEN.

Las mismas leyes no se aplican a sus propias variables; aquí usted ya es responsable de la sintaxis. Las variables se pueden configurar localmente en cada tarea.

O globalmente al almacén de variables y luego vincularlos desde el almacén. Muy cómodamente.

Como beneficio adicional, si las variables son muy secretas, se pueden almacenar en la nube de Azure en un almacenamiento llamado Azure Vault; puede vincular Vault al proyecto en la Biblioteca;

En general, todo está claro con las variables; en los pipelines aún se pueden configurar manualmente para cada lanzamiento; en la versión no existe tal funcionalidad. Puede ver lo que está transfiriendo a la canalización nuevamente en los registros de inicialización del agente, pero tenga en cuenta que ya están allí en formato convertido.

Variables dinámicas

La diversión comienza cuando queremos recibir algún valor en una etapa y pasarlo a la siguiente.

No se nos proporcionó dicha funcionalidad. Pero nuestras manos no están para aburrirse y con la ayuda de Google se encontró una solución. Gracias a Dios, Azure DevOps tiene una API que nos permite hacer un poco más de lo que se muestra en la interfaz.

Por lo tanto, necesitaremos una llamada para actualizar las variables globales, lo cual haremos directamente desde el proceso. La dirección se toma de variables de entorno, las mismas sobre las que no hay ni una palabra en la documentación, como se mencionó anteriormente. Puedes configurarlos tú mismo o, lo que es más, codificarlos si cierran la tienda.

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

Establecemos el valor vacío de la variable que queremos transferir, configuramos Alcance - Liberación

Por ejemplo, creamos algún generador de valores aleatorios. Preste atención a la sintaxis de declarar una variable dentro de esta etapa se introdujo esta funcionalidad;

En el siguiente paso le pasamos la variable al script, sí, sí, no se puede directamente, debe ser mediante un argumento.

Guión bajo spoiler

PowerShell

#Script requires stageVar variable in release variables set to Release scope

param ( [string] $expVar )
#region variables
$ReleaseVariableName = 'StageVar'
$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


#region Update StageVar with new value
$release.variables.($ReleaseVariableName).value = "$expVar"
#endregion

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

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

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

Bash

INPUT_VAR=$1
RELEASE_VAR=$2

echo Test ID: ${INPUT_VAR}

RELEASE_URL="${SYSTEM_TEAMFOUNDATIONSERVERURI}${SYSTEM_TEAMPROJECTID}/_apis/release/releases/${RELEASE_RELEASEID}?api-version=5.0"

echo release url: $RELEASE_URL

RELEASE_JSON=$(curl -H "Authorization: Bearer $SYSTEM_ACCESSTOKEN" $RELEASE_URL)

OUTPUT=`jq ''.variables.${RELEASE_VAR}.value' = '"${INPUT_VAR}"'' <<< $RELEASE_JSON`

curl -H "Authorization: Bearer $SYSTEM_ACCESSTOKEN" -H "Content-Type: application/json" -X PUT -d "$OUTPUT" $RELEASE_URL

En pocas palabras, nuestro script toma la variable myVar como entrada y usa la API para poner el valor de esta variable en stageVar. En el siguiente paso, utilizando la sintaxis de las variables del sistema, podemos verlo.

El ejemplo es bastante simple, pero la funcionalidad nos abre buenas oportunidades, además de mis anteriores. artículo, cuando podemos crear una máquina virtual en la primera etapa de prueba, realizar algunas manipulaciones adicionales con ella y varias en paralelo. Y la etapa final es destruirlo. Ahora ejecutamos pruebas automáticas del producto cada vez en máquinas virtuales nuevas. Teniendo en cuenta que viven unos 10 minutos, cuesta un centavo.

En el próximo artículo, si es necesario, hablaré sobre los canales YAML; últimamente ha habido muchas innovaciones interesantes allí.

Fuente: habr.com

Uso de variables en canalizaciones de Azure DevOps

Almacenamiento y uso

Variables dinámicas