Continuamos nossa análise de uma ferramenta maravilhosa de desenvolvimento para Windows e muito mais, o Azure DevOps. Desta vez, tendo sofrido muito com variáveis de ambiente, resolvi colocar toda a experiência em um só artigo.
A começar pelo fato de possuírem sintaxe diferente para cada ambiente de execução, terminando pela falta de uma capacidade padrão de transferência de variáveis de um estágio do pipeline para outro.
Farei uma ressalva que os principais exemplos estarão em Release Pipelines, pois o YAML ainda não chegou lá e preciso da funcionalidade de muitos estágios e muitos artefatos. Parece que isso se tornou disponível em Pipelines regulares, o que praticamente os iguala em funcionalidade. No Pipelines YAML, adicionamos uma pequena dica gráfica à representação do texto com parâmetros que podem ser definidos. É muito conveniente; você não precisa passar pela documentação de cada módulo. Mas vou descrever isso no próximo artigo, mas por enquanto aqui está uma foto da inovação em si.
Armazenamento e uso
Vamos começar com o fato de que temos variáveis padrão no sistema. Eles começam, dependendo da sua origem, com as palavras Liberação, Sistema, etc. A lista completa (ao que parece, não), está disponível em . Toda esquizofrenia com sintaxe é ilustrada por um exemplo da documentação abaixo. A mesma variável possui 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 no qual a tarefa é executada, ela será $(System.AccessToken). Caso queira utilizá-lo dentro de um script powershell no mesmo agente, já será $env:SYSTEM_ACCESSTOKEN. Se você, Deus me livre, quiser usar essa variável em algum host remoto usando a tarefa PowerShell nas máquinas de destino, precisará passar isso por meio de um argumento para o script usando . Com o bash é mais simples, você pode simplesmente passá-lo para dentro usando o argumento e a sintaxe $SYSTEM_ACCESSTOKEN.
As mesmas leis não se aplicam às suas próprias variáveis; aqui você já é responsável pela sintaxe. As variáveis podem ser definidas localmente em cada tarefa.
Ou globalmente para o armazenamento de variáveis e, em seguida, vincule-as ao armazenamento. Muito confortavelmente.
Como bônus, se as variáveis forem muito secretas, elas poderão ser armazenadas na nuvem do Azure em um armazenamento chamado Azure Vault; você pode vincular o Vault ao projeto na Biblioteca.
Em geral, tudo fica claro com variáveis; em pipelines elas ainda podem ser definidas manualmente para cada lançamento; no lançamento não existe tal funcionalidade. Você pode ver o que está transferindo para o pipeline novamente nos logs de inicialização do agente, mas lembre-se de que eles já estão lá no formato convertido.
Variáveis Dinâmicas
A diversão começa quando queremos receber algum valor em uma etapa e passar para a próxima.
Não nos foi fornecida essa funcionalidade. Mas as nossas mãos não estão para o tédio e com a ajuda do Google foi encontrada uma solução. Graças a Deus, o Azure DevOps possui uma API que nos permite fazer um pouco mais do que estava representado na interface.
Portanto, precisaremos de uma chamada para atualizar variáveis globais, o que faremos diretamente de dentro do pipeline. O endereço é retirado de variáveis de ambiente, as mesmas sobre as quais não há uma palavra na documentação, conforme mencionado anteriormente. Você mesmo pode configurá-los ou, além do mais, codificá-los caso eles fechem a loja.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )Definimos o valor vazio da variável que queremos transferir, definimos Escopo - Liberação
Por exemplo, fazemos algum gerador de valores aleatórios. Preste atenção na sintaxe de declaração de uma variável dentro deste estágio; esta funcionalidade foi introduzida.
No próximo passo passamos a variável para o script, sim, sim, não é possível diretamente, deve ser através de um argumento.
Roteiro sob 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_URLResumindo, nosso script pega a variável myVar como entrada e usa a API para colocar o valor dessa variável em stageVar. Na próxima etapa, usando a sintaxe da variável do sistema, podemos examiná-la.
O exemplo é bastante simples, mas a funcionalidade abre boas oportunidades para nós, além do meu anterior , quando podemos criar uma máquina virtual no primeiro estágio de teste, realizar algumas manipulações adicionais com ela e várias em paralelo. E a etapa final é destruí-lo. Agora executamos autotestes do produto sempre em máquinas virtuais novas. Considerando que vivem cerca de 10 minutos, custa um centavo.
No próximo artigo, se necessário, falarei sobre pipelines YAML; tem havido muitas inovações interessantes ultimamente.
Fonte: habr.com