I. Codebase – Uma única base de código para múltiplos deploys

Garantir que todas as versões da aplicação estejam sincronizadas e centralizadas.

1º Fator: Código Base Único (One Codebase, Many Deploys)

O primeiro fator da metodologia de doze fatores afirma que deve haver um único código base (codebase) para uma aplicação, a partir do qual ela pode ser implantada em múltiplos ambientes (deploys). Essa ideia de “Código Base Único” pode parecer confusa para desenvolvedores iniciantes, especialmente porque pode dar a impressão de que toda a aplicação deve estar confinada em um único diretório ou repositório no Git. No entanto, o conceito vai muito além de apenas onde o código está armazenado.

O Que Realmente Significa “Código Base Único”?

Código Base Único refere-se à prática de manter uma única base de código para uma aplicação, que pode ser implantada em diferentes ambientes (como desenvolvimento, homologação, produção). Não significa que todos os arquivos relacionados à aplicação precisam estar em um único diretório ou repositório, mas que cada aplicação tem seu próprio repositório de código-fonte principal, e este repositório deve ser o ponto central de controle para a aplicação em todos os ambientes.

Chaves para Entender o Conceito:

1. Uma Aplicação, Um Repositório:
   • Para uma aplicação única (por exemplo, um sistema de gestão de clientes), você terá um repositório principal no Git, onde o código-fonte é versionado e mantido. Isso garante que o histórico de alterações e a evolução da aplicação estejam centralizados em um único lugar.
   • Exemplo Angular: Uma aplicação Angular, ao seguir este princípio, tem seu repositório Git principal onde todo o código do frontend é versionado. Esse repositório contém os arquivos src/, package.json, angular.json, entre outros, e é a única fonte de verdade para essa aplicação.
2. Múltiplos Deploys, Uma Base de Código:
   • A mesma base de código pode ser implantada em diferentes ambientes, como:
     • Ambiente de Desenvolvimento: Onde os desenvolvedores estão testando localmente.
     • Ambiente de Homologação (Staging): Onde a versão quase final da aplicação é testada antes do lançamento em produção.
     • Ambiente de Produção: Onde a aplicação está disponível para os usuários finais.
   • Cada um desses ambientes usa a mesma base de código, mas pode ter configurações diferentes (por exemplo, variáveis de ambiente para URLs de APIs, chaves de autenticação, etc.), garantindo que a lógica da aplicação seja consistente em todos os deploys.
3. Monorepo vs Multirepo:
   • Um repositório pode conter o código de uma única aplicação ou seguir o modelo de monorepo, onde vários projetos relacionados (como frontend e backend) compartilham o mesmo repositório. No entanto, cada aplicação individual deve seguir a regra de ter um único repositório que serve de fonte para seus diferentes deploys.
   • Monorepo: Em um monorepo, você pode ter uma pasta para o frontend (Angular) e outra para o backend, mas ambos devem ser versionados de maneira única. O importante aqui é que cada aplicação tenha sua base de código definida e organizada de forma clara.
4. Aplicações Distribuídas ou Microsserviços:
   • Para arquiteturas mais complexas, como as baseadas em microsserviços, cada microsserviço deve ter sua própria base de código. Isso significa que, para uma aplicação composta por vários serviços, cada serviço (ou componente) tem seu próprio repositório. Embora sejam partes de um sistema maior, cada serviço é tratado como uma aplicação isolada, com seu código, testes, e configurações específicas.
   • Exemplo Angular + Backend: Se você tem uma aplicação Angular consumindo APIs de um backend (por exemplo, um serviço em Node.js), o código do frontend Angular será mantido em um repositório separado do backend. Ambos os repositórios podem ser implantados em diferentes ambientes, mas cada um tem sua própria base de código e configurações.

Como Esse Princípio Se Aplica a Aplicações Angular

No caso de uma aplicação Angular, o repositório central é onde o código-fonte do frontend é armazenado e versionado. Aqui estão alguns detalhes de como esse fator se aplica:

• Repositório Git: A aplicação Angular tem seu repositório no Git (ou outro sistema de controle de versão), e todos os desenvolvedores trabalham nessa base de código única. O mesmo código que está em desenvolvimento será o que eventualmente será implantado em produção, garantindo consistência.
• Deploys Diferentes, Mesma Base de Código: Embora o código seja o mesmo em todos os ambientes, as configurações podem mudar. Por exemplo, os arquivos environment.ts e environment.prod.ts no Angular permitem que a aplicação se comporte de maneira diferente em desenvolvimento e produção. Isso pode incluir URLs de APIs, chaves de autenticação, ou níveis de log.
• CD/CI (Continuous Deployment/Integration): Ferramentas de integração contínua (CI) como Jenkins, GitLab CI ou GitHub Actions podem ser usadas para testar e implantar essa mesma base de código em diferentes ambientes de deploy. A base de código permanece a mesma, mas pode haver variações nas configurações de ambiente para se adequar ao propósito de cada deploy.

Casos Onde O Código Base Único Pode Ser Confundido

1. Frontends e Backends:
   • Algumas vezes, os desenvolvedores podem pensar que o código base único implica que todo o código do sistema, incluindo frontend e backend, deve estar em um único repositório. Na realidade, cada aplicação distinta (o frontend Angular, por exemplo) pode ter seu próprio repositório. O backend pode ter seu próprio código base, e ambos coexistem como sistemas separados.
2. Aplicações Monolíticas vs. Microsserviços:
   • Em uma arquitetura monolítica, o código base único pode conter o frontend e o backend juntos, especialmente se eles estiverem fortemente integrados. No entanto, em arquiteturas de microsserviços, cada serviço tem seu próprio código base único. Portanto, uma aplicação composta por vários serviços terá múltiplos repositórios (um para cada serviço).
3. Múltiplas Instâncias da Mesma Aplicação:
   • Uma única aplicação pode ser implantada em várias instâncias ou clientes diferentes. Por exemplo, uma aplicação SaaS (Software como Serviço) pode ter múltiplos deploys para diferentes clientes, mas ainda assim, todo esse processo deve partir de um único código base para garantir consistência.

Benefícios de Manter um Código Base Único

1. Consistência: Um único repositório de código garante que todos os desenvolvedores estejam trabalhando na mesma base de código, sem versões divergentes ou mudanças não rastreadas.
2. Escalabilidade: O código pode ser implantado em múltiplos ambientes, como desenvolvimento, homologação e produção, sem a necessidade de gerenciar múltiplas versões do código.
3. Portabilidade: Manter uma única base de código facilita a migração entre diferentes ambientes de hospedagem (local, nuvem, etc.) e simplifica a aplicação de patches e atualizações.

Conclusão

O princípio de Código Base Único é essencial para garantir que o desenvolvimento, teste e produção de uma aplicação Angular (ou qualquer outra) sigam uma abordagem consistente e centralizada. Não significa que toda a aplicação esteja em um único diretório ou repositório, mas sim que cada aplicação distinta tem sua própria base de código, versionada e controlada centralmente, a partir da qual pode ser implantada em múltiplos ambientes. Esse princípio garante consistência, escalabilidade e facilidade de manutenção, ao mesmo tempo que permite flexibilidade na forma como o código é gerenciado e implantado.