X. Dev/Prod Parity – Manter desenvolvimento e produção o mais semelhantes possível

Reduzir as lacunas entre os ambientes para garantir consistência e evitar surpresas.

10º Fator: Paridade entre Desenvolvimento e Produção (Dev/Prod Parity)

O décimo fator da metodologia de doze fatores trata da paridade entre os ambientes de desenvolvimento, homologação e produção, ou seja, manter esses ambientes o mais semelhantes possível. A ideia é reduzir as diferenças que costumam existir entre o que é desenvolvido localmente, o que é testado em homologação, e o que é implantado em produção, garantindo que o código funcione da mesma forma em todos os ambientes. Essa prática é fundamental para a implantação contínua, permitindo que as alterações sejam lançadas rapidamente e com menos riscos de falhas.

Gaps Comuns entre Desenvolvimento e Produção

Historicamente, há três tipos principais de lacunas entre os ambientes de desenvolvimento e produção:

Lacuna de Tempo:
- Em ambientes tradicionais, o tempo entre o desenvolvimento de um código e sua implantação em produção pode ser de semanas ou meses. Isso cria uma desconexão entre o que foi desenvolvido e como ele funciona no ambiente real.
Lacuna de Pessoas:
- Muitas vezes, os desenvolvedores escrevem o código, mas não estão envolvidos no processo de implantação ou no monitoramento da aplicação em produção. Equipes de operações fazem o deploy e cuidam da produção, criando uma barreira entre quem desenvolve e quem implanta.
Lacuna de Ferramentas:
- O ambiente de desenvolvimento frequentemente usa um conjunto diferente de ferramentas e tecnologias em comparação ao ambiente de produção. Por exemplo, um desenvolvedor pode usar SQLite no desenvolvimento local, enquanto a produção usa PostgreSQL. Essa diferença entre ferramentas pode levar a comportamentos inesperados no código ao ser promovido para produção.

Angular e Paridade entre Ambientes

No contexto de Angular, um framework frontend que roda no navegador, a aplicação geralmente não sofre tanto com lacunas diretas entre desenvolvimento e produção em termos de código e execução, porque o Angular é compilado em arquivos estáticos (HTML, CSS, JS), que são iguais em todos os ambientes após o processo de build. Contudo, existem fatores externos que afetam a aplicação Angular, principalmente o backend e os serviços de apoio (APIs, bancos de dados, caches, etc.) que ela consome.

Os seguintes elementos podem causar diferenças entre ambientes:

APIs e Serviços de Backend: Durante o desenvolvimento, a aplicação Angular pode consumir APIs locais ou mockadas, enquanto em produção ela consome APIs reais, com bancos de dados e serviços de produção. Se os ambientes de API não forem consistentes, pode haver incompatibilidades.
Configurações de Ambiente: O Angular usa arquivos de configuração (environment.ts, environment.prod.ts) para definir variáveis de ambiente, como URLs de APIs ou modos de execução. Se essas configurações não estiverem bem gerenciadas, a aplicação pode funcionar corretamente em desenvolvimento, mas falhar em produção.

Reduzindo as Lacunas: Dev/Prod Parity no Angular

A fim de manter a paridade entre desenvolvimento e produção, algumas práticas são recomendadas:

Reduzir o Tempo entre Deploys:
- Usar práticas de CI/CD (Continuous Integration/Continuous Deployment) para reduzir o tempo entre a escrita do código e sua implantação em produção. Isso pode ser feito com pipelines automatizados que testam e implantam o código rapidamente, em questão de horas ou minutos.
- No Angular, ferramentas como Jenkins, GitLab CI, ou GitHub Actions podem ser configuradas para automatizar o build e o deploy da aplicação Angular em ambientes de teste e produção.
Unificar o Processo de Deploy:
- Em vez de delegar a responsabilidade do deploy exclusivamente para equipes de operações, os desenvolvedores devem estar envolvidos no processo de implantação e monitoramento em produção. Isso pode ser facilitado por ferramentas como Docker, que permitem criar ambientes semelhantes ao de produção localmente.
- Com Docker, os desenvolvedores podem rodar containers localmente que imitam o ambiente de produção, com a mesma versão de banco de dados, servidores de cache, e outros serviços que a aplicação Angular consome.
Usar as Mesmas Ferramentas nos Diferentes Ambientes:
- Evitar diferenças entre os serviços de apoio: Durante o desenvolvimento, o ideal é que a aplicação Angular consuma os mesmos tipos de serviços que a produção. Por exemplo, se a produção usa PostgreSQL, o ambiente de desenvolvimento também deveria usar PostgreSQL, em vez de uma versão simplificada como SQLite. Isso minimiza o risco de diferenças no comportamento do código entre ambientes.
- Ferramentas de Mocking e Simulação: Em situações onde o uso dos mesmos serviços de produção não é prático (por exemplo, integração com APIs de terceiros), é possível usar ferramentas de mocking e simulação para garantir que o comportamento seja o mais próximo possível do ambiente de produção.
Usar Ferramentas de Provisionamento e Containers:
- Ferramentas como Docker e Kubernetes podem ser usadas para garantir que o ambiente de desenvolvimento seja o mais próximo possível da produção. Os desenvolvedores podem criar containers que simulam os mesmos bancos de dados, serviços de cache, e filas que estarão em produção, garantindo que o código seja testado em condições similares.
- Docker Compose pode ser usado para rodar localmente uma instância do backend, banco de dados, e até mesmo simular o ambiente de produção de forma local, garantindo consistência.

Exemplo de Paridade com Docker e Angular

Vamos ver um exemplo prático de como garantir a paridade entre desenvolvimento e produção com Docker:

Dockerfile para o Angular: O código Angular pode ser empacotado em um container Docker, garantindo que o ambiente de build seja o mesmo em todos os lugares:

FROM node:16-alpine as build
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
RUN npm run build --prod

2. Docker Compose para Ambientes de Produção e Desenvolvimento: Um docker-compose.yml pode ser usado para orquestrar o ambiente de desenvolvimento localmente com um banco de dados PostgreSQL e uma API simulada:

version: '3'
services:
  angular-app:
    build: .
    ports:
      - "4200:80"
  api:
    image: my-api:latest
    environment:
      - DATABASE_URL=postgres://db_user:db_pass@db:5432/mydb
  db:
    image: postgres:12
    environment:
      POSTGRES_USER: db_user
      POSTGRES_PASSWORD: db_pass

Aqui, a mesma configuração de banco de dados e API pode ser usada localmente, simulando o ambiente de produção para garantir que a aplicação Angular se comporte da mesma forma em ambos os ambientes.

Benefícios da Paridade Dev/Prod

Menos Surpresas em Produção: Quanto mais semelhantes forem os ambientes de desenvolvimento e produção, menores as chances de comportamentos inesperados ao migrar o código para produção.
Deploy Contínuo: A paridade entre os ambientes permite que novas versões do código sejam lançadas de forma contínua, com menos fricção, incentivando um ciclo de desenvolvimento mais ágil e responsivo.
Menos Retrabalho: A unificação das ferramentas e serviços entre os ambientes elimina a necessidade de ajustes adicionais ou correções que muitas vezes surgem quando os ambientes são significativamente diferentes.

Conclusão

Manter a paridade entre desenvolvimento e produção é um princípio fundamental para garantir que o código seja testado e implantado de forma rápida, confiável e sem surpresas. Para aplicações Angular, isso significa garantir que as APIs, serviços de backend, e ferramentas utilizadas no desenvolvimento local ou em homologação sejam o mais próximo possível do ambiente de produção, utilizando ferramentas como Docker para garantir consistência e simplificar o ciclo de deploy.

The Twelve-Factor App