🥇Uso de variáveis em pipelines Azure DevOps

Continuamos a análise da incrível ferramenta de desenvolvimento para Windows e além, o Azure DevOps. Desta vez, após lidar com variáveis de ambiente, decidi consolidar toda a experiência em um único artigo.

Desde o fato de que para cada ambiente de execução eles têm uma sintaxe diferente, até a ausência de uma maneira padrão de transferir variáveis de um estágio do pipeline para outro.

Devo mencionar que os principais exemplos serão em Release Pipelines, pois o YAML ainda não chegou lá, e eu preciso da funcionalidade de vários estágios e diversos artefatos. Parece que isso ficou disponível nos Pipelines comuns, o que praticamente igualou sua funcionalidade. No Pipelines, o YAML foi aprimorado e, além da representação textual, uma pequena dica gráfica com os parâmetros que podem ser definidos foi adicionada. Muito conveniente, não é preciso consultar a documentação para cada módulo. Mas isso vou descrever no próximo artigo, e por enquanto, aqui está a imagem da nova funcionalidade.

Armazenamento e uso

Comecemos pelo fato de que na sistema temos variáveis padrão. Elas começam, dependendo da origem, com as palavras Release, System, etc. A lista completa (como se viu, não existe) está disponível em documentação. Toda a confusão de sintaxe é ilustrada pelo exemplo da documentação abaixo. Para a mesma variável, existem três representações, dependendo de onde a chamamos.

steps:
 - bash: echo Este script pode usar $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "Este é um script que pode usar $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Se você definir uma variável no agente em que a tarefa está sendo executada, é $(System.AccessToken). Se você quiser usá-la 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, utilizando a tarefa PowerShell em máquinas de destino, precisará passá-la como argumento para o script, usando param. Com bash é mais simples, você pode apenas repassar usando argumento e sintaxe $SYSTEM_ACCESSTOKEN.

As mesmas regras não se aplicam às suas próprias variáveis, aqui você é responsável pela sintaxe. As variáveis podem ser definidas localmente em cada tarefa.

Ou globalmente no repositório de variáveis e, em seguida, vinculá-las a partir do repositório. Muito conveniente.

Como um bônus, se as variáveis forem altamente secretas, elas podem ser armazenadas na nuvem Azure em um repositório chamado Azure Vault, e a Vault pode ser linkada ao projeto na Biblioteca.

No geral, as variáveis estão claras; nos pipelines, elas podem ser definidas manualmente para cada execução, mas esse recurso não está disponível nas liberações. Você pode verificar o que está sendo passado para o pipeline nas logs de inicialização do agente, mas tenha em mente que lá elas já estão em formato transformado.

Variáveis dinâmicas

A parte mais interessante começa quando queremos obter um determinado valor em uma etapa e passá-lo para a próxima.

Esse recurso ainda não foi introduzido. Mas nossas mãos não são para ficar paradas, e com a ajuda do Google encontramos uma solução. Graças a Deus, o Azure DevOps tem uma API que nos permite fazer um pouco mais do que foi desenhado na interface.

Portanto, precisamos fazer uma chamada para atualizar variáveis globais, que faremos diretamente de dentro do pipeline. O endereço é retirado das variáveis de ambiente, aquelas que não são mencionadas em nenhum lugar na documentação, como mencionado anteriormente. Você pode defini-las você mesmo ou, ora, codificá-las diretamente, caso eles fechem a torneira.

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

Definimos um valor vazio para a variável que queremos passar, definimos o Escopo — Liberação.

Como exemplo, criamos um gerador de valores aleatórios. Observe a sintaxe de declaração da variável dentro desta etapa, esse recurso foi adicionado.

Na próxima etapa, passamos a variável para o script; sim, diretamente não é possível, precisa ser por meio de um argumento.

Script sob o 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

Em poucas palavras, nosso script recebe a variável myVar como entrada e, usando a API, coloca o valor dessa variável em stageVar. Na próxima etapa, usando a sintaxe de variáveis do sistema, podemos visualizá-la.

O exemplo é bastante simples, mas a funcionalidade nos oferece boas oportunidades, junto com minha experiência anterior. o artigo, quando podemos criar uma máquina virtual na primeira fase de testes, fazer algumas manipulações com ela e, simultaneamente, várias ao mesmo tempo. E, na etapa final, destruí-la. Atualmente, temos testes automatizados do produto sendo executados a cada vez em novas máquinas virtuais. Considerando que elas vivem por cerca de 10 minutos, isso custa uma quantia irrisória.

No próximo artigo, se necessário, falarei sobre pipelines YAML, onde há muitas novidades interessantes recentemente.

Fonte: habr.com

Uso de variáveis em pipelines do Azure DevOps

Armazenamento e uso

Variáveis dinâmicas