Recentemente, deparei-me com uma fera não tão popular no mundo do DevOps, os pipelines do Azure DevOps. Imediatamente senti a ausência de instruções ou artigos claros sobre o tópico, não sei com o que ele está conectado, mas a Microsoft claramente tem algo com o que trabalhar em termos de promoção da ferramenta. Hoje, criaremos um pipeline para testes automatizados dentro da nuvem do Azure.

Então, a tarefa:
Existem softwares criados com o mesmo Azure DevOps, montados a partir de um projeto no WIX. Se houver interesse, escreverei sobre esta ferramenta. Na verdade, essa é uma maneira mais automatizada de criar instaladores do Windows, que substitui o InstallShield padrão. Portanto, nosso software cria e gera com sucesso um artefato, um determinado setup.exe, que coloca o aplicativo em um sistema Windows. É necessário colocar esse aplicativo em uma máquina virtual semelhante a um produto, copiar os testes automatizados preparados pela equipe de testes, executá-los e coletar os resultados para considerar o ramo bom ou ruim antes da mesclagem. Tudo é como no GitLab, apenas através de ....

Como um ambiente de virtualização onde executaremos nossos testes, obviamente usamos o Azure DevTest Labs, uma entidade nas assinaturas do Azure, criada para distorcer todo tipo de absurdo de teste por um preço razoável.

1. Integração do lado da nuvem

Primeiro, precisamos integrar nosso DevTest Labs ao Azure DevOps, para o qual precisamos de algum Service Principal, essencialmente uma conta de serviço que permita acessar os pipelines na nuvem e criar / excluir recursos para nós mesmos.

Vá para a assinatura e encontre o serviço do Azure Active Directory



Encontramos Registros de Aplicativos e clique em Novo Registro, isso criará nosso principal de serviço. Não analisarei quais configurações escolherei ao criar. Isso pode ser diferente para assinaturas diferentes.



Agora precisamos dar direitos ao nosso diretor de serviço. Para fazer isso, vá para o ícone de assinatura com uma chave. Escolha nossa assinatura.



Em seguida, em Controle de acesso, clique em Atribuição de função e procure essa conta na pesquisa pelo nome que você acabou de criar. Damos o papel de Colaborador, isso é suficiente.



Em seguida, volte ao nosso Principal de serviço no Azure AD e abra suas propriedades. Mais tarde, precisaremos de todos os IDs existentes, salvá-los.

É aqui que nossas configurações do portal terminam e vamos para o Azure DevOps.

2. Integração no lado do Azure DevOps

Primeiro, vamos às configurações do projeto e selecionamos Conexões de Serviço. Crie um novo elemento do tipo Azure Resource Manager.



Agora precisamos de todos os IDs que gravamos. Clique em usar a versão completa da caixa de diálogo de conexão de serviço. E insira todos os dados que recebemos do responsável pelo serviço. Clique em verificar e, se estiver tudo bem, mantenha a conexão. Agora, nossos pipelines podem usá-lo para conectar-se à nuvem.

3. Criando um pipeline

Agora vamos para o mais interessante, a construção do próprio gasoduto. Abra o menu Pipelines-Builds



Somos recebidos por um menu para criar uma nova compilação, que por padrão tentará criar um arquivo YAML para nós com uma configuração adequada. Recusamos educadamente isso e escolhemos a versão clássica. O desejo da Microsoft de fazer tudo como pessoas e dar a oportunidade de personalizar pipelines através do YAML, tanto quanto possível, mas a documentação escassa e a inoperabilidade prática de muitos módulos nos dizem que é muito cedo para usar essa funcionalidade.



A partir da variedade de modelos, precisamos de um simples pipeline vazio. Após a sua criação, somos recebidos por uma janela de edição vazia, na qual passaremos muito tempo.



Então, clique em + e entre em um determinado repositório de módulos, de onde precisaremos dos seguintes componentes da lista.



Antes de prosseguirmos com a configuração da tarefa de pipeline, precisamos criar e colocar vários arquivos no projeto. Esses serão o Modelo ARM da nossa máquina virtual, que geraremos no Azure DevTest Labs, o script para obter a máquina IP após a criação e, se desejado, os scripts de nossos testes ou o que queremos executar no host.

4. Geração de modelo ARM

Para criar uma máquina virtual, primeiro precisamos gerar um modelo para ela, um arquivo json, que inserimos no código do projeto para que possa ser lido a partir daí pelo pipeline.

Vamos ao nosso laboratório e encontramos o menu Fórmulas (bases reutilizáveis), clique para criar um novo.



Seremos recebidos por uma longa lista de imagens como base, a escolha do tamanho da máquina, da mesma forma que na criação de uma máquina virtual. Nesta fase, não vamos parar, iremos imediatamente para o último item das propriedades da máquina, ou seja, artefatos. Você pode usar as configurações necessárias para o seu ambiente. Por exemplo, adiciono uma máquina ao domínio e adiciono uma conta de serviço como administrador, para que o pipeline possa acessar essa máquina nessa conta. Tudo isso pode variar, mas para um teste bem-sucedido do código, precisamos de um artefato, no qual iremos nos aprofundar mais detalhadamente. Para colocar a versão mais recente do software que testamos em nossa máquina, usaremos o artefato Download Download Pipelines Azure Artfact e Run Script. Lembra no começo que eu disse que em algum lugar uma compilação está acontecendo com o instalador do aplicativo? Agora precisamos dizer à máquina virtual, ou melhor, ao modelo, para que ele vá e pegue esse artefato. E não apenas o peguei, mas também o defini, para o qual preenchemos campos especiais indicando o projeto, o nome da construção e a chave secreta. A chave secreta, como em todos os sistemas desse tipo, é gerada na conta, nesse caso no Azure DevOps e armazenada em Segredos no seu laboratório. Há uma pequena ressalva: em Secrets, vamos salvá-lo, mas não é frio nem calor; ele será lançado a partir de outro usuário como parte do pipeline; portanto, precisaremos inserir manualmente a chave secreta novamente no modelo.

Outro artefato que deve ser incluído é o “Configure WinRM”, precisamos dele para acesso subseqüente à máquina. Existe apenas um parâmetro, nome do host. Como não sabemos com antecedência, usaremos a variável% COMPUTERNAME%.



Então, nós adicionamos todos os artefatos necessários. Vamos seguir por que viemos aqui. Obtemos o modelo ARM gerado na guia Avançado da mesma janela de criação de fórmula.



Copie o conteúdo da página para o arquivo VMtemplate.json e coloque-o na raiz do projeto. Não precisamos mais da nuvem, estamos retornando ao pipeline.

5. Configuração de Pipeline

Vamos começar com o mais importante e interessante, criando uma máquina virtual. Para isso, fizemos todas essas integrações e modelos. Na assinatura do Azure RM, selecionamos nossa conexão de serviço, configurada no parágrafo 2. Em seguida, o ambiente de laboratório disponível será exibido. Depois, selecionamos json que geramos e definimos algumas variáveis ​​obrigatórias. O nome de usuário e a senha do carro podem ser definidos diretamente ou com variáveis, mas não tenho certeza de que funcione, o que quer que eu escreva lá, não consegui entrar no carro com esses créditos, o principal é definir o nome do carro para que seja sempre possível único. Para isso, eu uso a variável de ambiente build.



Em seguida, estabelecemos outro ponto importante. Depois que o carro decola, também precisamos conhecer seus parâmetros de alguma forma, e é melhor não para nós, mas para a linha de pagamento. Para fazer isso, criamos um script, por exemplo, GetLabVMParams.ps1 e o colocamos lá, no projeto. Peguei o texto do script no site da Microsoft, mas o corrigi levemente para o meu ambiente, porque ele levou máquinas PublicIP e FQDN. Eu não tenho nenhum, mas há o PrivateIP que não é tão fácil de obter, então adicionei um artigo.

Param( [string] $labVmId) $labVmComputeId = (Get-AzureRmResource -Id $labVmId).Properties.ComputeId # Get lab VM resource group name $labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName # Get the lab VM Name $labVmName = (Get-AzureRmResource -Id $labVmId).Name # Get lab VM public IP address # $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress # Get lab VM FQDN # $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn # Get lab VM private IP address $VmNetworkdetails= (((Get-AzureRmVM -ResourceGroupName $labVmRgName -Name $labVmName).NetworkProfile).NetworkInterfaces).Id $nicname = $VmNetworkdetails.substring($VmNetworkdetails.LastIndexOf("/")+1) $labVMnetwork = (Get-AzureRmNetworkInterface -Name $nicname -ResourceGroupName $labVmRgName)|Select-Object -ExpandProperty IPConfigurations $labVMIpAddress = $labVMnetwork.PrivateIpAddress # Set a variable labVmRgName to store the lab VM resource group name Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName" # Set a variable labVMIpAddress to store the lab VM Ip address Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress" # Set a variable labVMFqdn to store the lab VM FQDN name Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn" Write-Output $labVMIpAddress Set-Item wsman:\localhost\client\trustedhosts * -Force 

De tudo o que o script lê, precisamos apenas da variável labVMIpAddress. Bem, isso é para mim, talvez você precise de algo mais, por isso eu não apaguei nada e apenas comentei o excesso.

Também explicarei a última linha do script, que permite à nossa máquina de compilação acessar qualquer host via WinRM.

O próximo passo, executamos nosso maravilhoso script. Ele precisará da mesma conexão com a nuvem, a variável de entrada com o ID da máquina, que naquele momento já seria conhecido na etapa anterior. Como Aqui é necessário mencionar algo tão maravilhoso como variáveis ​​de saída. Cada etapa pode ter uma lista de variáveis ​​que são passadas para as próximas etapas do pipeline. Assim, para o nosso super script, essa variável será labVMIpAddress, não se esqueça de indicar isso.



Além disso, faço coisas bastante simples, que, além disso, podem variar de caso para caso. Eu executo um script remoto com a criação de bolas, no qual carregarei meus scripts.

 New-Item “C:\test" –type directory New-SMBShare –Name “test” –Path “C:\test” –FullAccess everyone 

Pelo nome dos repolhos, fica claro que, em seguida, copiamos algum script de amostra para a máquina e o executamos em outra etapa. Como o endereço da máquina remota, nossa variável $ (labVMIpAddress) é útil para nós. Em seguida, usamos a tarefa “pegar o artefato das bolas” e copiamos os resultados do script para o nosso ambiente de construção; em seguida, salvamos esses arquivos no artefato de construção com a mesma tarefa padrão. Depois que não precisamos mais do carro, o matamos com o último passo. A principal dificuldade, como pode ser visto no volume do artigo, é integrar-se à nuvem e estabelecer contato com a máquina virtual que você criou, para que você já possa se divertir o quanto precisar.

Este é o meu primeiro artigo, portanto, não julgue estritamente, comentários são bem-vindos.