Continuamos coa nosa revisión dunha ferramenta marabillosa para o desenvolvemento para Windows e moito máis, Azure DevOps. Esta vez, despois de sufrir moito coas variables de ambiente, decidín poñer toda a experiencia nun mesmo artigo.
Partindo de que teñen unha sintaxe diferente para cada contorno de execución, rematando coa falta dunha capacidade estándar para transferir variables dunha fase da canalización a outra.
Vou facer unha reserva de que os exemplos principais estarán en Release Pipelines, porque YAML aínda non chegou e necesito a funcionalidade de moitas etapas e moitos artefactos. Isto, ao parecer, chegou a estar dispoñible en Pipelines habituais, o que practicamente os iguala en funcións. En Pipelines YAML, engadimos unha pequena información gráfica á representación do texto con parámetros que se poden establecer. É moi cómodo, non tes que pasar pola documentación de cada módulo. Pero describirei isto no seguinte artigo, pero de momento aquí tes unha imaxe da propia innovación.
Almacenamento e uso
Imos comezar co feito de que temos variables predeterminadas no sistema. Comezan, segundo a súa orixe, coas palabras Release, System, etc. A lista completa (como resulta que non), está dispoñible en . Toda a esquizofrenia con sintaxe ilústrase cun exemplo da documentación que aparece a continuación. A mesma variable ten tres representacións, dependendo de onde a chamemos.
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)Se estableces unha variable no axente no que se executa a tarefa, é $(System.AccessToken). Se queres usalo dentro dun script de Powershell no mesmo axente, xa será $env:SYSTEM_ACCESSTOKEN. Se queres usar esta variable nalgún host remoto usando a tarefa PowerShell en máquinas de destino, debes pasar isto a través dun argumento ao script usando . Con bash é máis sinxelo, simplemente podes pasalo dentro usando o argumento e a sintaxe $SYSTEM_ACCESSTOKEN.
As mesmas leis non se aplican ás túas propias variables; aquí xa es responsable da sintaxe. As variables pódense establecer localmente en cada tarefa.
Ou globalmente á tenda de variables e, a continuación, vinculalas desde a tenda. Moi cómodamente.
Como extra, se as variables son moi secretas, pódense almacenar na nube de Azure nun almacenamento chamado Azure Vault; podes vincular Vault ao proxecto na Biblioteca.
En xeral, todo está claro coas variables; nas canalizacións aínda se poden configurar manualmente para cada lanzamento; na versión non hai tal funcionalidade. Podes ver o que estás a transferir á canalización de novo nos rexistros de inicialización do axente, pero ten en conta que xa están alí convertidos.
Variables dinámicas
A diversión comeza cando queremos recibir algún valor nunha etapa e pasalo á seguinte.
Non nos proporcionaron tal funcionalidade. Pero as nosas mans non son para o aburrimento e coa axuda de Google atopouse unha solución. Grazas a Deus, Azure DevOps ten unha API que nos permite facer un pouco máis do que se representa na interface.
Polo tanto, necesitaremos unha chamada para actualizar as variables globais, o que faremos directamente desde a canalización. O enderezo está tomado de variables de ambiente, as mesmas das que non hai nin unha palabra na documentación, como se mencionou anteriormente. Podes configuralos ti mesmo ou, ademais, codificalos se pechan a tenda.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )Establecemos o valor baleiro da variable que queremos transferir, establecemos Scope - Release
Por exemplo, facemos un xerador de valores aleatorios. Preste atención á sintaxe de declarar unha variable dentro desta etapa; esta funcionalidade foi introducida.
No seguinte paso, pasamos a variable ao script, si, si, non é posible directamente, debe ser a través dun argumento.
Guión baixo 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))
#endregionOu
Bater
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_URLEn poucas palabras, o noso script toma a variable myVar como entrada e usa a API para poñer o valor desta variable en stageVar. No seguinte paso, usando a sintaxe das variables do sistema, podemos miralo.
O exemplo é bastante sinxelo, pero a funcionalidade ábrenos boas oportunidades, ademais da miña anterior , cando podemos crear unha máquina virtual na primeira fase da proba, realizar algunhas manipulacións máis con ela, e varias en paralelo. E a fase final é destruílo. Agora realizamos probas automáticas do produto cada vez en máquinas virtuais novas. Tendo en conta que viven uns 10 minutos, custa un centavo.
No seguinte artigo, se é necesario, falarei dos pipelines YAML; últimamente houbo moitas innovacións interesantes.
Fonte: www.habr.com