Automação de teste e o pipeline de entrega

Você aprendeu mais sobre a implantação contínua e a entrega de software e serviços, mas os dois são, na verdade, parte de uma tríade. As práticas de DevOps visam alcançar integração contínua, entrega e implantação. Normalmente, essas práticas são criadas nessa ordem, com cada uma dependendo da anterior.

Agora é hora de fazer uma pausa e discutir a primeira delas: integração. Isso faz parte do processo de desenvolvimento que vem antes da implantação. O DevOps recomenda uma prática de desenvolvimento em que os membros da equipe frequentemente integram o código a um repositório compartilhado que contém uma só base de código "principal" ou "tronco". A meta é fazer com que todos contribuam com o código que será enviado em oposição ao trabalho na respectiva cópia e só reunir tudo no último minuto.

Os testes automatizados podem verificar a integração de cada membro da equipe. Essa testagem ajuda a determinar que o código está "saudável" após cada alteração e adição feita. O teste faz parte do que normalmente é chamado de pipeline. O restante desta unidade se concentra em pipelines de teste e entrega integrados.

O pipeline de entrega contínua

Para entender a função dos testes automatizados no modelo de implantação de entrega contínua, você precisa ver onde eles se encaixam no pipeline de entrega. Um pipeline de entrega contínua é a implementação do conjunto de etapas executado pelo código conforme as alterações são feitas durante o processo de desenvolvimento antes de implantá-lo em produção. Esta é uma representação gráfica das etapas de exemplo em um pipeline de entrega simplificado:

Acompanhe este pipeline passo a passo:

• Uma instância do pipeline é iniciada conforme as alterações de código ou de infraestrutura são confirmadas em um repositório de código, talvez usando uma solicitação de pull.

• Em seguida, os testes de unidade são executados, geralmente seguidos por testes de integração ou de ponta a ponta. Os resultados são comunicados de volta ao desenvolvedor que abriu a solicitação de pull.

• Neste estágio, o código no repositório geralmente é verificado quanto a segredos, vulnerabilidades e configurações incorretas.

• Quando tudo está em ordem, o código é construído e preparado para implantação.

• Em seguida, o código é implantado em um ambiente de teste. Um revisor pode ser notificado sobre a nova implantação para que possa examinar a solução de pré-produção. Em seguida, o revisor aprova ou nega a promoção à produção, que inicia a parte final do processo de implantação que libera o código para produção.

Nesse pipeline, você pode observar a delineação entre integração e implantação. Os marcadores realçados apontam alguns locais lógicos em que você pode parar o pipeline por meio de lógica e automação incluídas, ou potencialmente até mesmo intervenção humana.

Ferramentas para integração e entrega contínuas: Azure Pipelines e GitHub Actions

Para usar a integração e a entrega contínuas, você precisará das ferramentas certas. Microsoft oferece duas opções de CI/CD de primeira parte para compilar e implantar em Azure: Azure Pipelines (parte do Azure DevOps) e GitHub Actions. Ambos podem automatizar a criação e o teste consistente de seu código e ambos podem ser implantados em serviços Azure, máquinas virtuais e outros destinos na nuvem e no local. Muitas equipes adotam GitHub Actions quando seu código-fonte já vive em GitHub, enquanto Azure Pipelines continua sendo uma escolha forte para equipes padronizadas em Azure DevOps.

O restante desta unidade se concentra em Azure Pipelines, mas GitHub Actions usa ideias de alto nível semelhantes, embora a terminologia seja diferente. Em GitHub Actions, fluxos de trabalho contém tarefas e etapas, ações criam pacotes de automação reutilizável, executores realizam o trabalho e ambientes podem proteger implementações.

A entrada para um pipeline (seu código ou configurações) reside em um sistema de controle de versão, como GitHub ou outro provedor Git.

Azure Pipelines é executado em recursos computacionais, como uma máquina virtual ou um contêiner, e oferece agentes de build hospedados pela Microsoft que rodam Windows, Linux e macOS. Você também pode registrar seus próprios agentes autohospedados quando precisar de controle total sobre o ambiente de compilação. Ele também oferece integração com plug-ins de teste, segurança e qualidade de código. Por fim, ele é facilmente extensível, para que você possa implementar sua própria automação no Azure Pipelines.

Os pipelines são definidos usando a sintaxe YAML armazenada junto com seu código em um repositório Git. Os pipelines YAML são a abordagem recomendada para novos projetos. Uma interface de usuário clássica no Azure DevOps também está disponível para pipelines legados, mas a maioria das novas funcionalidades (incluindo trabalhos em contêineres e muitos recursos avançados) é exclusiva do YAML. Os pipelines também fornecem modelos que você pode usar para criar facilmente pipelines, como um modelo para uma imagem do Docker ou um projeto Node.js. Você também pode reutilizar um arquivo YAML existente.

As etapas básicas para configurar um pipeline são:

1. Configure Azure Pipelines para usar o repositório Git.
2. Defina sua compilação editando o arquivo azure-pipelines.yml (ou, para pipelines legados, usando o editor clássico).
3. Faça push do seu código para o repositório de controle de versão. Essa ação dispara o pipeline para compilar e testar o código.

Depois que o código for atualizado, criado e testado, você poderá implantá-lo em qualquer destino desejado.

Construção do pipeline Azure

Os pipelines são estruturados em:

• Trabalhos: um trabalho é um agrupamento de tarefas ou de etapas executadas em um só agente de build. Um trabalho é o menor componente da atividade que pode ser agendado para execução. Todas as etapas de um trabalho são executadas em sequência. Essas etapas podem ser qualquer ação necessária, incluindo a criação ou compilação de software, a preparação de dados de exemplo para testes, a execução de testes específicos e assim por diante.

• Fases: uma fase é um agrupamento lógico de trabalhos relacionados.

Cada pipeline tem, pelo menos, um estágio. Use vários estágios para organizar o pipeline em divisões principais e marque os pontos no seu pipeline, no qual você pode pausar e executar verificações.

Os pipelines podem ser tão simples ou complexos quanto você precisar. Para tutoriais sobre a construção e uso de pipelines, consulte o roteiro de aprendizagem Build applications with Azure DevOps.

Rastreabilidade de ambiente

Há um outro aspecto dos pipelines relacionados à confiabilidade que vale a pena mencionar. Você pode construir seus pipelines de modo que seja possível correlacionar o que está sendo executado em produção com uma instância de build específica. Idealmente, você deve ser capaz de rastrear um build de volta para uma solicitação de pull específica ou alteração de código. Essa rastreabilidade é inestimável durante um incidente e, posteriormente, durante a revisão pós-incidente, quando você está tentando identificar qual alteração contribuiu para um problema. Alguns sistemas de CI/CD (como Azure Pipelines e GitHub Actions) tornam essa correlação simples, enquanto outros exigem que você construa manualmente um pipeline que propaga uma ID de build em cada estágio.