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 destinam-se a alcançar a integração, a implantação e a entrega contínuas.

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. Esse teste ajuda a determinar que o código é "íntegro" depois de cada alteração e adição ser feita. O teste faz parte do que chamamos de pipeline. Falaremos sobre os pipelines daqui a pouco, pois esta unidade terá como foco os pipelines de teste e de 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:

Vamos percorrer esse 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, serão executados testes unitários, talvez testes de integração ou de ponta a ponta, e o ideal é que os resultados desses testes sejam comunicados de volta à parte solicitante.

• Talvez nesse ponto, o código no repositório seja examinado em busca de segredos, vulnerabilidades e aspectos de configuração.

• Quando é feito check-out de tudo, o código é criado e preparado para implantação.

• Em seguida, o código é implantado em um ambiente de teste. Uma pessoa pode ser notificada da nova implantação para dar uma olhada na solução de pré-produção. Essa pessoa pode, então, aprovar ou negar a implantação para a produção, o que inicia a parte final do processo de implantação que libera o código na produção.

Nesse pipeline, você pode observar a delineação entre integração e implantação. Os marcadores vermelhos apontam alguns locais lógicos os quais você pode interromper o pipeline por meio da lógica e da automação incluídas ou potencialmente até mesmo a intervenção humana.

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

Para usar a integração e a entrega contínuas, você precisará das ferramentas certas. O Azure Pipelines faz parte do Azure DevOps Services que você pode usar para automatizar o build e o teste consistentes do seu código. Você também pode usar o Azure Pipelines para implantar o código nos serviços do Azure, em máquinas virtuais e em outros destinos na nuvem e no local.

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

O Azure Pipelines executado em uma parte da computação, como uma máquina virtual ou um contêiner, oferece agentes de build que executam o Windows, o Linux e o macOS. Ele também oferece integração a plug-ins de teste, segurança e qualidade de código. Por fim, ele é facilmente extensível para que você possa colocar sua automação no Azure Pipelines.

Os pipelines são definidos por meio da sintaxe YAML ou da interface do usuário Clássica no portal do Azure. Ao usar um arquivo YAML, você pode armazenar esse arquivo junto com o código. Os pipelines também fornecem modelos que você pode usar para criar pipelines com facilidade. Por exemplo, um pipeline que cria uma imagem do Docker ou um projeto do Node.js. Você também pode reutilizar um arquivo YAML existente.

Independentemente de você usar um arquivo YAML ou a interface Clássica, estas são as etapas básicas:

1. Configure o Azure Pipelines para usar seu repositório Git.
2. Defina o build, editando o arquivo azure-pipelines.yml ou usando o editor Clássico.
3. Efetue push do 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.

Há alguns recursos (como a execução de trabalhos de contêiner) que só estão disponíveis por meio do YAML, e outros (como grupos de tarefas) que só estão disponíveis por meio da interface Clássica.

Construção do Azure Pipeline

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 tipo de ação desejada, incluindo criação/compilação de software, preparação de dados de exemplo para teste, execução de testes específicos etc.

• 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 desejado. Há excelentes tutoriais sobre a construção e o uso do pipeline no roteiro de aprendizagem Construir aplicativos com o 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. O ideal é que possamos rastrear um build novamente a uma PR ou a uma alteração de código específica. Isso poderá ser extremamente útil durante um incidente ou mais tarde durante a revisão pós-incidente quando você estiver tentando identificar a alteração que contribuiu para um problema. Alguns sistemas de CI/CD (como o Azure Pipelines) facilitam essa tarefa, enquanto outros exigem que você construa manualmente um pipeline que propague um tipo de "ID de build" por todas as fases.