Continuamos analisando a maravilhosa ferramenta de desenvolvimento para Windows e não apenas o Azure DevOps. Dessa vez, atormentado por variáveis de ambiente, decidi colocar toda a experiência em um artigo.Começando pelo fato de que para cada ambiente de tempo de execução, eles têm sintaxe diferente, terminando com a falta de uma capacidade padrão de transferir variáveis de um estágio do pipeline para outro.Farei uma reserva de que os principais exemplos estarão nos Pipelines de Lançamento, porque o YAML ainda não o alcançou e preciso da funcionalidade de muitos estágios e muitos artefatos. Parece que isso ficou disponível em pipelines regulares, que praticamente os nivelaram em funcionalidade. Nos Pipelines, o YAML adicionou e adicionou à exibição de texto uma pequena dica de ferramenta gráfica com parâmetros que podem ser definidos. Muito conveniente, não há necessidade de entrar na documentação de cada módulo. Mas vou descrever isso no próximo artigo, mas por enquanto, aqui está uma imagem da própria inovação.
Armazenamento e uso
Para começar, temos variáveis padrão no sistema. Eles começam, dependendo da origem, com as palavras Liberação, Sistema, etc. Uma lista completa (como se vê, não) está disponível na documentação . Toda esquizofrenia com sintaxe é ilustrada por um exemplo da documentação abaixo. A mesma variável tem três representações, dependendo de onde a chamamos.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 você definir uma variável no agente que está executando a tarefa, será $ (System.AccessToken). Se você quiser usá-lo dentro de um script do PowerShell no mesmo agente, ele já será $ env: SYSTEM_ACCESSTOKEN. Se, Deus permita, você deseja usar essa variável em algum host remoto usando a tarefa do PowerShell nas máquinas de destino, precisará passar isso por um argumento para o script usando param . Com o bash mais simples, você pode simplesmente usar o argumento e a sintaxe $ SYSTEM_ACCESSTOKEN.As mesmas leis não se aplicam a suas próprias variáveis; aqui você já é responsável pela sintaxe. Você pode definir variáveis localmente em cada tarefa.
Ou globalmente no repositório de variáveis e, em seguida, vincule-as a partir do repositório. Muito confortavelmente.
Como um bônus, se as variáveis forem muito secretas, elas poderão ser armazenadas na nuvem do Azure em um armazenamento chamado Azure Vault, o Vault poderá ser vinculado ao projeto na Biblioteca.
Em geral, tudo fica claro com as variáveis, nos pipelines você ainda pode defini-las manualmente para cada inicialização, no release não existe essa funcionalidade. Você pode ver o que transfere para o pipeline novamente nos logs de inicialização do agente, mas observe que eles já estão no formulário convertido lá.
Variáveis dinâmicas
A parte mais interessante começa quando queremos obter algum valor em um estágio e passá-lo para o próximo.
Essa funcionalidade não foi entregue a nós. Mas nossas mãos não são para o tédio e, com a ajuda do Google, foi encontrada uma solução. Graças a Deus, o Azure DevOps tem uma API que nos permite fazer um pouco mais do que desenhamos na interface.Portanto, precisamos de uma chamada para atualizar variáveis globais, o que faremos desde o interior do pipeline. O endereço é obtido de variáveis de ambiente, as mesmas das quais não há uma palavra na documentação, conforme mencionado anteriormente. Você pode perguntar a si mesmo ou, o que há, codificar se eles fecharem a loja.$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )
Defina o valor vazio da variável que queremos passar, defina Scope - Release.Porexemplo, criamos algum gerador aleatório de valores. Preste atenção à sintaxe da declaração da variável dentro desse estágio; essa funcionalidade foi introduzida.
Na próxima etapa, passamos a variável para o script, sim, sim, é impossível diretamente, é necessário através do argumento.
O script sob o spoilerPowerhell
param ( [string] $expVar )
$ReleaseVariableName = 'StageVar'
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )
Write-Host "URL: $releaseurl"
$Release = Invoke-RestMethod -Uri $releaseurl -Headers @{
Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
Write-Output ('Release Pipeline variables output: {0}' -f $($Release.variables | ConvertTo-Json -Depth 10))
$release.variables.($ReleaseVariableName).value = "$expVar"
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" }
Write-Output ('Get updated Release Definition')
Write-Host "URL: $releaseurl"
$Release = Invoke-RestMethod -Uri $releaseurl -Headers @{
Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
Write-Output ('Updated Release Pipeline variables output: {0}' -f $($Release.variables | ConvertTo-Json -Depth 10))
OuBaterINPUT_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
Em poucas palavras, nosso script pega a variável de entrada myVar e, usando a API, coloca o valor dessa variável em stageVar. Na próxima etapa, usando a sintaxe das variáveis do sistema, podemos ver isso.
O exemplo é bastante simples, mas a funcionalidade nos oferece boas oportunidades, no total com meu último artigo , quando podemos criar uma máquina virtual no primeiro estágio do teste, fazer algumas manipulações adicionais e várias ao mesmo tempo. E o passo final é destruí-lo. Agora, estamos sempre buscando autoteste de produto em novas máquinas virtuais. Dado que eles vivem por 10 minutos, vale um centavo.No próximo artigo, se necessário, falarei sobre os pipelines YAML, há muitas inovações interessantes ultimamente.