Microsserviço 7

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

Dentro desta 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 afetou o comportamento do sistema; 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 um 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.

Pipeline

Em uma pipeline de CD, várias etapas compõem o processo de build, e uma dessas etapas gera um artefato. Outras etapas podem incluir a 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 para ser lançada, mas o lançamento depende de uma análise de qualidade para decidir se a versão está pronta para ser implantada. Na implantação contínua, todas as mudanças aprovadas por validações automatizadas são automaticamente implantadas sem intervenção humana.

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.

Código-Fonte

Para 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.

No uso 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 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 façam a modificação;
• 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.