Automatização de teste e o pipeline de entrega

Você aprendeu 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 DevOps visam alcançar integração, entrega e implementação contínuas. Estas práticas são normalmente construídas por essa ordem, com cada uma a depender da anterior.

Agora, é hora de fazer backup e discutir o primeiro deles: a integração. Tal faz parte do processo de desenvolvimento que surge antes da implementação. O DevOps recomenda uma prática de desenvolvimento em que os membros da equipa integram frequentemente código num repositório partilhado que contém uma base de código "principal" ou "tronco". O objetivo é que todos contribuam para o código que será implementado, ao invés de trabalharem nas suas próprias cópias e apenas reunirem tudo no último minuto.

Os testes automatizados podem então verificar a integração de cada membro da equipe. Estes testes ajudam a determinar se o código está em "bom estado de funcionamento" após cada alteração e adição efetuadas. Os testes fazem parte do que é comumente chamado de pipeline. O restante desta unidade concentra-se em pipelines integrados de testes e entrega.

O fluxo de entrega contínua

Para entender o papel do teste automatizado no modelo de implantação de entrega contínua, você precisa analisar onde ele se encaixa no pipeline de entrega. Um pipeline de entrega contínua é a implementação do conjunto de passos pelo qual o código passa à medida que as alterações são efetuadas durante o processo de desenvolvimento antes de implementá-lo na produção. Aqui está uma representação gráfica de etapas de exemplo em um pipeline de entrega simplificado:

Percorra este processo passo a passo:

• Uma instância do pipeline começa quando alterações de código ou de infraestrutura são cometidas a um repositório de código, talvez utilizando um pull request.

• De seguida, são executados testes unitários, frequentemente seguidos por testes de integração ou de ponta a ponta. Os resultados são comunicados de volta ao desenvolvedor que abriu o pull request.

• Nesta fase, o código do repositório é frequentemente analisado à procura de segredos, vulnerabilidades e configurações erradas.

• Quando tudo estiver verificado, o código é compilado e preparado para implementação.

• Em seguida, o código é implementado num ambiente de teste. Um revisor pode ser notificado da nova implementação para que possa examinar a solução de pré-produção. O revisor aprova ou recusa então a promoção para produção, o que inicia a parte final do processo de implementação que liberta o código para produção.

Neste pipeline, pode-se observar a delimitação entre integração e implantação. Os marcadores destacados indicam alguns pontos estratégicos onde pode interromper o pipeline utilizando a lógica e automação disponíveis, ou potencialmente até intervenção humana.

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

Para utilizar a integração e entrega contínuas, precisa das ferramentas certas. Microsoft oferece duas opções de CI/CD de primeira parte para construir e implementar em Azure: Azure Pipelines (parte do Azure DevOps) e GitHub Actions. Ambos podem automatizar a construção e o teste consistente do seu código, e ambos podem ser implementados em serviços Azure, máquinas virtuais e outros alvos na cloud e on-premises. Muitas equipas adotam o GitHub Actions quando o seu código-fonte já está presente no GitHub, enquanto o Azure Pipelines continua a ser uma escolha forte para equipas padronizadas no Azure DevOps.

O restante desta unidade foca-se no Azure Pipelines, mas o GitHub Actions utiliza ideias de alto nível semelhantes, mesmo que a terminologia seja diferente. No GitHub Actions, os fluxos de trabalho contêm trabalhos e etapas, as ações embalam automação reutilizável, os runners executam o trabalho e os ambientes podem proteger as implementações.

A entrada para um pipeline (o seu código ou configurações) reside num sistema de controlo de versões como o GitHub ou outro fornecedor Git.

Azure Pipelines é executado em infraestruturas de computação, como máquinas virtuais ou containers, e oferece agentes de build hospedados pela Microsoft que executam Windows, Linux e macOS. Também pode registar os seus próprios agentes auto-hospedados quando precisar de controlo total sobre o ambiente de construção. Também oferece integração com plug-ins de teste, segurança e qualidade de código. Por fim, é facilmente extensível, por isso podes trazer a tua própria automação para o Azure Pipelines.

Os pipelines são definidos usando sintaxe YAML armazenada juntamente com o seu código num repositório Git. Os pipelines YAML são a abordagem recomendada para novos projetos. Uma interface de utilizador clássico no Azure DevOps também está disponível para pipelines legados, mas a maioria das novas funcionalidades (incluindo tarefas de contentores e muitas funcionalidades avançadas) funciona apenas com YAML. Os pipelines também fornecem modelos que pode usar para criar pipelines facilmente, como um modelo para uma imagem Docker ou um projeto Node.js. Pode reutilizar um ficheiro YAML existente.

Os passos básicos para configurar um pipeline são:

1. Configure o Azure Pipelines para usar o seu repositório Git.
2. Defina a sua build editando o ficheiro azure-pipelines.yml (ou, para pipelines legados, usando o editor Classic).
3. Envie seu código para o repositório de controle de versão. Esta ação aciona o pipeline para compilar e testar o seu código.

Quando o código tiver sido atualizado, compilado e testado, pode implementá-lo em qualquer alvo que pretender.

Construção do Azure Pipeline

Os pipelines são estruturados em:

• Trabalhos: um trabalho é um agrupamento de tarefas ou etapas que é executado em um único agente de compilação. Um trabalho é o componente mais pequeno da atividade que pode agendar para executar. Todos os passos num trabalho são executados sequencialmente. Esses passos podem ser qualquer ação que precises, incluindo construir ou compilar software, preparar dados de exemplo para testes, executar testes específicos, e assim por diante.

• Estágios: Um estágio é um agrupamento lógico de trabalhos relacionados.

Cada pipeline tem pelo menos uma fase. Utilize várias etapas para organizar o pipeline em divisões principais e marcar os pontos no seu pipeline onde pode fazer uma pausa e realizar verificações.

Os pipelines podem ser tão simples ou complexos quanto você precisar. Para tutoriais sobre a construção e utilização de pipelines, consulte o percurso de aprendizagem Build aplicações com Azure DevOps.

Rastreabilidade de ambiente

Há um outro aspeto dos pipelines relacionado à confiabilidade que vale a pena mencionar. Você pode construir seus pipelines de tal forma que seja possível correlacionar o que está sendo executado em produção com uma instância de compilação específica. Idealmente, deves conseguir rastrear uma compilação até um pull request específico ou alteração de código. Esta rastreabilidade é inestimável durante um incidente e, posteriormente, durante a revisão pós-incidente, quando tenta identificar qual alteração contribuiu para um problema. Alguns sistemas CI/CD (como Azure Pipelines e GitHub Actions) tornam esta correlação simples, enquanto outros exigem que construas manualmente um pipeline que propague um ID de build por cada etapa.