Microsserviço 7

Iniciando o uso de microsserviços, precisamos rever o processo de desenvolvimento para acomodar esse novo estilo de arquitetura.

Dentro dessa revisão, um ponto de grande importância é a integração contínua (CI) e a entrega contínua (CD).

Quando falamos em CI, o principal objetivo é manter todos em sincronia, ou seja, garantir que alterações no código sejam integradas ao código principal o mais cedo possível. Queremos criar artefatos que serão validados e reutilizados em todas as implantações dessa versão do código.

Exemplos de boas práticas de CI incluem:

• Integração com a branch principal com a maior frequência possível;
• Execução de testes, pois, sem eles, saberemos apenas que a integração foi bem-sucedida sintaticamente, mas não se terá certeza de que o comportamento do sistema não foi afetado; e
• Correção de problemas na build: todos os check-ins que não estejam diretamente envolvidos na correção de uma build com erro devem ser interrompidos até que o problema seja resolvido.

Já o objetivo do CD é manter uma pipeline que gere um artefato, o qual passará por várias etapas até ser entregue ao ambiente de produção.

Modelos de Branches

Trabalhar com branches permite que o desenvolvimento seja feito de forma isolada, sem interferir no trabalho de outras pessoas. No entanto, todos os membros do time que estão trabalhando em uma branch devem integrá-la à branch principal com frequência. Branches de longa duração devem ser evitadas.

Artefato

O artefato criado no processo de build será utilizado em todas as etapas da pipeline de CD. Configurações que variam de acordo com o ambiente devem ser mantidas fora do artefato em si.

Pipeline

Em uma pipeline de CD, várias etapas compõem o processo de build, por exemplo: geração do artefato, execução de testes, verificação de vulnerabilidades, aprovação em UAT e, finalmente, implantação em produção. Esse processo deve ser percorrido pelo mesmo artefato gerado inicialmente.

Além da CD, temos a implantação contínua. A diferença é que, na CD, cada nova mudança é candidata a uma nova versão a ser lançada, mas o lançamento depende de uma análise de qualidade para decidir se a versão está pronta para implantação. Na implantação contínua, todas as mudanças aprovadas por validações automatizadas são automaticamente implantadas, sem intervenção humana.

Código-Fonte

Para a gestão do código-fonte no repositório, temos três abordagens:

• Repositório único;
• Repositório por microsserviço; e
• Monorepo.

No caso de um repositório único, há um único repositório que armazena todo o código e gera uma única build. Com essa abordagem, os lançamentos precisam ser sincronizados e vários serviços são implantados ao mesmo tempo. Uma alteração mínima em um serviço faz com que todos os serviços sejam reconstruídos e implantados, o que é ineficiente e geralmente indesejável.

Na abordagem de repositório por microsserviço, cada projeto tem seu repositório de código-fonte, e qualquer mudança no código envolve a construção apenas do projeto correspondente. Contudo, ao trabalhar com vários repositórios, alterações em diferentes repositórios não podem ser feitas de forma atômica. Um ponto importante é que, se mudanças contínuas impactam vários microsserviços, talvez as fronteiras dos serviços não estejam bem definidas, resultando em alto acoplamento entre eles. Nesses casos, considerar a fusão de alguns microsserviços pode ser vantajoso.

Na abordagem de monorepo, o código de vários microsserviços (ou outros tipos de projetos) é armazenado em um único repositório de código-fonte. Esse modelo permite que alterações de código feitas em diferentes projetos sejam realizadas de forma atômica. Para a construção de artefatos, pastas devem ser mapeadas para processos de build específicos, e cada diretório pode ter responsáveis designados. Uma vantagem do monorepo é que ele facilita a reutilização de código entre projetos e permite mudanças atômicas.

No monorepo, é importante definir responsabilidades para diferentes áreas do código. Esses modelos indicam quem é responsável por cada parte do repositório. Os tipos incluem:

• Responsabilidade forte: o código pertence a um grupo específico de pessoas. Se alguém fora desse grupo quiser fazer uma alteração, deve solicitar que os responsáveis a façam;
• Responsabilidade fraca: o código pertence a um grupo específico, mas pessoas de fora desse grupo têm permissão para fazer alterações, que devem ser revisadas pelos responsáveis; e
• Responsabilidade coletiva: qualquer pessoa pode fazer qualquer alteração no código.

De modo geral, a abordagem de repositório por microsserviço (multirepo) é mais simples e sustentável. No caso do monorepo, a dificuldade de gerenciamento tende a crescer conforme o número de softwares aumenta.