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 de DevOps visam alcançar integração, implantação e entrega contínuas.

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 na qual os membros da equipa integram frequentemente código num repositório partilhado com uma base de código "principal" ou "ramal". O objetivo é que todos contribuam para o código que será enviado ao invés de trabalhar na sua cópia e reunir tudo apenas 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. O teste faz parte do que chamamos de pipeline. Falaremos sobre pipelines em apenas um momento, porque esta unidade se concentrará em testes integrados e pipelines de entrega.

O pipeline 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:

Vamos percorrer este pipeline, passo a passo.

• Uma instância do pipeline começa quando as alterações de código ou de infraestrutura são consolidadas para um repositório de código, talvez ao utilizar um pedido Pull.

• Em seguida, os testes de unidade são executados — talvez testes de integração ou de ponta a ponta — e, idealmente, esses resultados de teste são comunicados de volta à parte solicitante.

• Talvez neste ponto, o código no repositório seja verificado em busca de segredos, vulnerabilidades e aspetos de configuração.

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

• Em seguida, o código é implementado num ambiente de teste. Uma pessoa pode ser notificada da nova implementação para dar uma vista de olhos na solução de pré-produção. Esta pessoa pode então aprovar ou negar a implementação para produção, que inicia a parte final do processo de implementação que liberta o código para a produção.

Neste pipeline, você pode observar a delimitação entre integração e implantação. Os marcadores vermelhos indicam alguns locais lógicos onde pode parar o pipeline através de lógica e automatização incluídas ou potencialmente até mesmo a intervenção humana.

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

Para utilizar a integração e entrega contínuas, precisa das ferramentas certas. O Azure Pipelines faz parte do Azure DevOps Services que pode utilizar para automatizar a compilação e testar consistentemente o seu código. Também pode utilizar o Azure Pipelines para implementar o código para serviços do Azure, máquinas virtuais e outros alvos, tanto na cloud como nas instalações.

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

O Azure Pipelines é executado num pedaço de computação, como uma máquina virtual ou um contentor, oferece agentes de compilação em execução no Windows, Linux e macOS. Ele também oferece integração com plug-ins de teste, segurança e qualidade de código. Finalmente, é facilmente extensível, para que você possa trazer sua própria automação para o Azure Pipelines.

Os pipelines são definidos através da sintaxe YAML ou através da interface de utilizador Clássica no portal do Azure. Quando utilizar um ficheiro YAML, pode armazenar esse ficheiro ao lado do seu código. Os pipelines também fornecem modelos que você pode usar para criar pipelines facilmente; por exemplo, um pipeline que cria uma imagem do Docker ou um projeto Node.js. Pode reutilizar um ficheiro YAML existente.

Se você usa um arquivo YAML ou a interface clássica, aqui estão as etapas básicas:

1. Configure o Azure Pipelines para utilizar o seu repositório do Git.
2. Defina sua compilação, editando o arquivo azure-pipelines.yml ou usando o editor Clássico.
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.

Há alguns recursos (como a execução de trabalhos de contêiner) que só estão disponíveis ao usar o YAML e outros (como grupos de tarefas) que só estão disponíveis usando a interface Classic.

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. Essas etapas podem ser qualquer tipo de ação desejada, incluindo a construção/compilação de software, a preparação de dados de amostra para testes, a execução de 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 fazes para organizar o pipeline em divisões maiores e marcar os pontos no seu pipeline em que pretende efetuar uma pausa e executar verificações.

Os pipelines podem ser tão simples ou complexos quanto quiser. Há excelentes tutoriais sobre construção e uso de pipeline no caminho de aprendizado Criar aplicativos com o 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, devemos ser capazes de rastrear uma compilação de volta a um PR específico ou alteração de código. Isso pode ser extremamente útil, durante um incidente ou depois 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 o Azure Pipelines) facilitam isso, enquanto outros exigem que você construa manualmente um pipeline que propaga algum tipo de "ID de compilação" por todos os estágios.