Planejar um pipeline de lançamento usando o Azure Pipelines
Nesta seção, você acompanha Paulo e Clara no planejamento de um pipeline de CD básico executado no Azure Pipelines.
Ao terminar, eles o demonstrarão ao restante da equipe. O pipeline servirá como uma POC que eles vão aprimorar e expandir à medida que aprenderem mais e receberem feedback de Pedro e Marina.
Quais são as partes de um pipeline de CD básico?
Um pipeline de CD básico contém um gatilho para fazer o processo sair e pelo menos uma fase ou estágio de implantação. Uma fase é composta por trabalhos. Um trabalho é uma série de etapas que definem como compilar, testar ou implantar seu aplicativo.
Paulo: Já temos o artefato de compilação 
. É o arquivo .zip criado pelo nosso pipeline de build. Porém, como implantá-lo em um ambiente ativo do 
?
O que é uma fase de pipeline?
Uma fase é uma parte do pipeline que pode ser executada de modo independente e ser disparada por mecanismos diferentes. Um mecanismo pode ser o sucesso da fase anterior, uma agenda ou até mesmo um gatilho manual. Você vai aprender mais sobre esses mecanismos no próximo módulo.
Clara: Poderíamos ter uma fase que compila o aplicativo e outra que executa os testes.
Clara: Já definimos as tarefas para a fase de build no pipeline. Nossa fase de implantação pode ser semelhante, incluindo tarefas que implantam o build em um ambiente.
A pergunta é: em que local devemos implantar o artefato?
O que é um ambiente?
Você provavelmente usou o termo ambiente para se referir ao local em que seu aplicativo ou serviço está em execução. Por exemplo, seu ambiente de produção pode ser o local em que os usuários finais acessam seu aplicativo.
Seguindo este exemplo, seu ambiente de produção pode ser:
- Um computador físico ou VM (máquina virtual).
- Um ambiente em contêineres, como Kubernetes.
- Um serviço gerenciado, como o Serviço de Aplicativo do Azure.
- Um ambiente sem servidor, como o Azure Functions.
Um artefato é implantado em um ambiente. O Azure Pipelines facilita a implantação em praticamente qualquer tipo de ambiente, seja local ou na nuvem.
No Azure Pipelines, o termo ambiente tem um segundo significado. Aqui, um ambiente é uma representação abstrata de seu ambiente de implantação, como um cluster do Kubernetes, uma instância do Serviço de Aplicativo ou uma máquina virtual.
Um ambiente do Azure Pipelines registra o histórico de implantação para ajudá-lo a identificar a origem das alterações. Usando ambientes do Azure Pipelines, você também pode definir verificações de segurança e maneiras de controlar como um artefato é promovido de uma fase do pipeline para outra. O que um ambiente inclui depende do que você deseja fazer com o artefato. Um ambiente no qual você deseja testar o artefato provavelmente será definido de modo diferente de um ambiente no qual você deseja implantar o artefato para os usuários finais.
Uma forma de definir um ambiente do Azure Pipelines é usando um arquivo YAML. O arquivo YAML inclui uma seção environment, que especifica o ambiente de Azure Pipelines no qual você implantará seu artefato.
Ao planejar seu pipeline de lançamento, você precisará decidir em que local seu aplicativo ou serviço será executado. Vamos escutar e ver o que Paulo e Clara decidem.
Paulo: Em um alto nível, que tipo de ambiente queremos? Queremos implantar localmente ou na nuvem?
Mara: Poderíamos pedir ao Tim para criar uma VM para nós no laboratório, mas ele está sempre ficando sem hardware. Será rápido e fácil configurar uma POC nós mesmos só se usarmos a nuvem.
Andy: Concordo, mas há tantas opções de nuvem a serem consideradas, e nós podemos usar o Azure Pipelines para implantar em qualquer uma delas. Qual devemos tentar?
Clara: As equipes que desenvolvem nossos jogos usam o Azure para hospedar alguns sistemas de back-end. Elas o configuram rapidamente e parecem gostar dele. Acho que devemos usar o Azure para nossa nuvem.
Andy: Ok, isso faz sentido! Mas o Azure fornece tantas opções de computação. Qual devemos escolher?
Paulo lista essas opções no quadro de comunicações:
- Máquinas virtuais
- Contêineres
- Serviço de Aplicativo do Azure
- Computação sem servidor
Observação
Você encontrará mais informações sobre cada uma dessas opções de computação no final deste módulo.
Clara: Sei que contêineres e computação sem servidor são populares no momento. Em comparação com as VMs, são leves em termos de recursos. Também são fáceis de serem substituídas e escaladas horizontalmente. Ambos são interessantes, mas estou angustiada quanto a aprender duas novas tecnologias ao mesmo tempo. Prefiro me concentrar apenas no build do pipeline.
Paulo: Concordo com você. Com isso, temos VMs ou o Serviço de Aplicativo. Acho que as VMs seriam uma opção melhor se estivéssemos movendo um aplicativo de linha de negócios – um que exigisse acesso completo a algum ambiente específico – para a nuvem. Não estamos fazendo nada tão significativo.
Clara: Então resta o Serviço de Aplicativo, que seria minha escolha. Ele foi projetado para funcionar com o Azure DevOps e tem suas vantagens. É um ambiente de PaaS (plataforma como serviço) para aplicativos Web, portanto, alivia grande parte da nossa carga. Não precisaremos nos preocupar com a infraestrutura. Ele também vem com recursos de segurança e nos permite executar balanceamento de carga e dimensionamento automático.
Paulo: O Serviço de Aplicativo parece ser o que precisamos. Vamos usar o Serviço de Aplicativo. Estamos criando apenas uma prova de conceito de qualquer forma. Sempre podemos alterar a opção de computação se quisermos tentar algo mais tarde.
Como o Azure Pipelines executa as etapas de implantação?
Para implantar seu aplicativo, o Azure Pipelines primeiro precisa se autenticar no ambiente de destino. O Azure Pipelines fornece mecanismos de autenticação diferentes. O que você usa depende do ambiente de destino para o qual você está implantando. Você encontrará mais informações sobre esses mecanismos no final deste módulo.
Paulo: Temos nosso artefato de compilação e sabemos que vamos criar e implantar em fases do pipeline. Também definimos o ambiente de destino para nossa implantação. Ele é o Serviço de Aplicativo. Minha pergunta agora é: como o Azure Pipelines se autentica com o Serviço de Aplicativo? Sei que essa será uma das preocupações de Pedro. Precisamos garantir que o processo seja seguro.
Depois de um pouco de pesquisa, Paulo e Clara elaboram as etapas gerais que permitem ao Azure Pipelines implantar no Serviço de Aplicativo:
- Especificar o ambiente de implantação de destino na configuração do pipeline.
- Fornecer um modo de o Azure Pipelines autenticar o acesso a esse ambiente.
- Usar tarefas do Azure Pipelines para implantar o artefato de compilação nesse ambiente.
Clara: De acordo com nossa pesquisa, precisamos criar uma conexão de serviço para especificar o ambiente de destino e autenticar o acesso a ele. Depois de definirmos a conexão de serviço, ela estará disponível para todas as nossas tarefas usarem. Em seguida, precisamos usar as tarefas internas DownloadPipelineArtifact para baixar o artefato de compilação no agente de pipeline e AzureWebApp para implantar o aplicativo no Serviço de Aplicativo do Azure.
O que são trabalhos e estratégias?
O pipeline de build existente define um agente de build, variáveis de pipeline e as tarefas necessárias para compilar seu software.
A parte de implantação do pipeline contém esses mesmos elementos. Sua configuração de implantação normalmente também define um ou mais trabalhos, um ambiente de pipeline e estratégias. Você aprendeu sobre ambientes de pipeline anteriormente.
Aqui está um exemplo de configuração que você executará mais adiante neste módulo. Essa configuração implanta o site do Space Game no Serviço de Aplicativo.
- stage: 'DeployDev'
displayName: 'Deploy to dev environment'
dependsOn: Build
jobs:
- deployment: Deploy
pool:
vmImage: 'ubuntu-20.04'
environment: dev
variables:
- group: 'Release Pipeline'
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: drop
- task: AzureWebApp@1
displayName: 'Azure App Service Deploy: website'
inputs:
azureSubscription: 'Resource Manager - Tailspin - Space Game'
appName: '$(WebAppName)'
package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'
Trabalhos
Um trabalho é uma série de etapas – ou tarefas – executadas em sequência como uma unidade. Cada fase do pipeline tem um trabalho por padrão, mesmo quando essa fase não usa a palavra-chave job.
Um trabalho pode ser executado em um pool de agentes, em um contêiner ou diretamente no Azure DevOps Server. O trabalho de exemplo mostrado aqui é executado em um agente Ubuntu hospedado pela Microsoft.
Você pode especificar as condições sob as quais cada trabalho é executado. O trabalho de exemplo mostrado aqui não define nenhuma condição. Por padrão, um trabalho será executado se ele não depender de nenhum outro trabalho ou se todos os trabalhos dos quais ele depender foram concluídos com êxito.
Você também pode executar trabalhos em paralelo ou em sequência. Usando o pipeline de build existente como exemplo, você pode usar trabalhos paralelos para criar seu software em agentes do Windows, do Linux e do macOS ao mesmo tempo.
Um trabalho de implantação é um tipo especial de trabalho que desempenha um papel importante nas fases de implantação. Os trabalhos de implantação registram o status das implantações no Azure Pipelines, fornecendo uma trilha de auditoria. Os trabalhos de implantação também ajudam a definir a estratégia de implantação, o que faremos em breve.
Estratégias
Uma estratégia define como o aplicativo é distribuído. Você aprenderá mais sobre estratégias como azul-verde e canário em um módulo futuro. Por enquanto, você usará a estratégia runOnce para baixar o pacote do Space Game do pipeline e implantá-lo no Serviço de Aplicativo do Azure.
Como o Azure Pipelines se conecta ao Azure?
Para implantar seu aplicativo em um recurso do Azure, como uma máquina virtual ou um Serviço de Aplicativo, você precisa de uma conexão de serviço. Uma conexão de serviço dá acesso seguro à sua assinatura do Azure usando um dos dois métodos:
- Autenticação de entidade de serviço
- Identidades gerenciadas dos recursos do Azure
Você pode saber mais sobre esses modelos de segurança no final deste módulo, porém, para resumir:
- Uma entidade de serviço é uma identidade com uma função limitada que pode acessar recursos do Azure. Considere uma entidade de serviço como uma conta de serviço que pode realizar tarefas automatizadas em seu nome.
- As identidades gerenciadas para recursos do Azure são um recurso do Microsoft Entra ID que simplifica o processo de trabalho com entidades de serviço. Como as identidades gerenciadas existem no locatário do Microsoft Entra, a infraestrutura do Azure pode autenticar automaticamente o serviço e gerenciar a conta para você.
As identidades gerenciadas simplificam o processo de trabalho com entidades de serviço; mas, neste módulo, usaremos a autenticação da entidade de serviço porque uma conexão de serviço pode descobrir automaticamente seus recursos do Azure e atribuir as funções de entidade de serviço apropriadas para você.
O plano
Paulo e Clara estão prontos para começar. Eles vão:
- Criar com base na configuração de build do Azure Pipelines existente.
- Definir uma fase de build que cria o artefato.
- Definir uma fase de implantação que implanta o artefato no Serviço de Aplicativo.
Paulo: Este desenho está correto? Usamos o Azure Pipelines para implantação no Serviço de Aplicativo . Para fazer isso, usamos o artefato de compilação 
como a entrada para a fase de implantação 
. As tarefas da fase de implantação baixam o artefato 
e usam uma conexão de serviço para implantar o artefato no Serviço de Aplicativo 
.
Clara: Isso requer somar. Vamos começar.