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 extrema 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, um código alterado deve ser integrado ao código principal o mais cedo possível. Queremos criar artefatos que serão validados, mas esses artefatos devem ser criados somente uma vez e utilizados em todas as implantações dessa versão de código.

Pontos que demonstram a utilização de CI são:

• integração com a branch principal com maior frequência possível.
• utilização de testes, já que sem os testes, saberemos apenas que, do ponto de vista sintático, a integração foi bem sucedida, mas não será possível dizer se causou falha no comportamento do sistema.
• problemas na build, todos os check-ins quem não estejam envolvidos na correção da build devem ser interrompidos até que a correção seja efetuada.

Já quando falamos em CD, o objetivo é ter um pipeline que gere um artefato que passe por várias etapas até a entrega no 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. O ponto é que todos do time que estejam trabalhando em uma branch deve fazer check-in da branch principal com frequência. Branches de longa duração devem ser evitadas.

Pipeline

Em uma pipeline de CD, teremos várias etapas no processo de build e uma dessas etapas que gera um artefato. Essas etapas podem ser execução de testes, check de vulnerabilidades, aprovação em UAT e, em última instância, implantação em produção. Claro que todas as etapas do pipeline serã percorridas 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 é candadata a uma nova versão a ser lançada, mas o lançamento depende de análise de qualidade e decisão se essa versão está pronta para ser implantada. No caso da implantação contínua, todas as mudanças são validadas com métodos automatizados e caso tenha sido aprovadas, serão automaticamente implantadas, sem intervenção humana.

Artefato

O mesmo artefato criado no processo de build será usado em todas as etapas da pipeline de CD. Agora, configurações que variem de ambiente devem ser mantidas fora do artefato propriamente dito.

Código-fonte

Para gestão do código-fonte no repositório, temos as abordagens:

• um repositório com tudo.
• um repositório por microsserviço.
• monorepo.

No caso de um repositório com tudo, teremos um único repositório que armazena todo o código e gera uma única build com tudo. Ao usar essa abordagem, teremos de aceitar que os lançamentos deverão ser sincronizados e vários serviços serão implantados de uma só vez. Uma alteração de uma linha em um serviço, tem como consequência todos os demais serviços deverão ser construídos e implantados. Definitivamente deve ser evitado.

Na abordagem de um repositório por microsserviço, cada projeto tem seu repositório de código-fonte e qualquer mudança no código envolverá a construção somente do projeto correspondente. A questão é que poderemos estar trabalhando com vários repositórios ao mesmo tempo e alterações não poderão ser feitas atomicamente nos diferentes repositório envolvidos. Um ponto que deve ser observado nessa abordagem é que se você faz continuamente mudanças envolvendo vários microsserviços, talvez as fronteiras dos microsserviços não estejam no lugar certo, o que gera um excesso de acoplamento entre os serviços. Talvez valha a pena considerar a fusão de alguns microsserviços.

No uso de monorepo, o código de vários microsserviços (ou outros tipos de projetos) é armazenado no mesmo repositório de códigos-fontes. A ideia é que alterações de código feitas em diferentes projetos possam ser realizadas de forma atômica. Para construção de artefatos, deve-se mapear pastas a um processo de construção. Além disso, diretórios específicos poderão ter responsáveis específicos. Uma das vantagens é que podemos ter a reutilização de código altamente especializada entre os projetos e a mudanças podem ser feitas atomicamente.

Ainda com monorepo, deve-se definir os diferentes modelos de responsabilidades. Esse modelo diz quem é responsável pelo que no repositório. Os tipos são:

• responsabilidade forte: o código pertence a um grupo específico de pessoas. Caso alguém fora desse grupo queira fazer uma alteração, deverá solicitar aos responsáveis para que façam a modificação.
• responsabilidade fraca: o código pertence a um grupo específico de pessoas. Entretando, pessoas fora do grupo de responsáveis têm permissão de fazer alterações, embora a alteração deverá ser revisada pelos responsáveis pelo código.
• responsabilidade coletiva: qualquer um pode fazer qualquer mudança no código.

De modo geral, a abordagem de um repositório por microsserviço (multirepo) acaba sendo uma solução mais simples e sustentável. A questão com monorepo é que, à medida que os softwares aumentam, a dificuldade de gerencimento tende a aumentar também.