Squad Front

Appearance

GitFlow e Gestão de Ambientes ​

Para garantir a estabilidade das nossas aplicações de saúde, utilizamos um fluxo de trabalho baseado em GitFlow integrado com nossos ambientes de deploy.

Nossos Ambientes ​

Trabalhamos com três ambientes principais, cada um com um propósito e nível de isolamento específico:

1. Desenvolvimento (Dev) ​

  • Propósito: Validação técnica inicial e testes de novas funcionalidades (Features).
  • Origem: Branch develop.
  • Acesso: Livre para desenvolvedores e QAs.
  • Dados: Dados sintéticos ou mocks.

2. Homologação (Staging) ​

  • Propósito: Validação final de UX/UI e QA em um ambiente idêntico ao de produção.
  • Origem: Branch staging.
  • Características Técnicas:
    • Espelhamento: É uma cópia exata de Produção (mesmas credenciais e infraestrutura).
    • Sincronização: Os dados são espelhados de Prod para Staging a cada 20 dias.
    • Anonimização: Durante o espelhamento, os dados sensíveis dos usuários são anonimizados para garantir a segurança e conformidade com a LGPD, mantendo o volume e a estrutura real para testes de performance.

3. Produção (Prod) ​

  • Propósito: Ambiente real de atendimento ao cidadão brasileiro.
  • Origem: Branch master.
  • Restrições: Deploy controlado e monitorado.

🛠️ O Fluxo de Trabalho (GitFlow) ​

Ramos de Vida Longa ​

  • master: Reflete o código em produção.
  • staging: Reflete o código em homologação.
  • develop: Reflete o código em desenvolvimento.

Fluxo de Desenvolvimento ​

  1. Novas Features: Criamos branchs sempre a partir da master (ex: feature/NOME-DA-TASK). Nunca inicie a partir de develop ou staging para evitar trazer bugs ou funcionalidades incompletas.
  2. Pull Request (PR): Após concluir, abrimos PR para develop.
  3. Deploy em Dev: Ao fazer merge na develop, o deploy automático ocorre para o ambiente de Dev.
  4. Promovendo para Staging: Quando a funcionalidade é validada em Dev, fazemos um PR da develop para a staging.
  5. Validação Final: O QA testa no ambiente de Staging (com os dados reais anonimizados).
  6. Release (Prod): Validado em Staging, o código segue para a master via PR, disparando o deploy para **Produção **.

Correções (Bugfix e Hotfix) ​

  • Bugfix: Se encontrar um bug em develop ou staging, crie a branch de correção a partir da branch onde o problema está.
    • Exemplo (Dev): bugfix/fix-auth-error a partir da develop.
    • Exemplo (Staging): bugfix/fix-auth-error a partir da staging.
  • Hotfix: Para correções urgentes em Produção, a branch deve ser criada sempre a partir da master.
    • Exemplo: hotfix/fix-error-queue.

✅ O que fazer ​

  • Sempre crie branchs com nomes semânticos (feature/, bugfix/, hotfix/).
  • Garanta que o código foi testado em Staging antes de subir para Produção.
  • Mantenha seu branch local de develop sempre atualizado.

❌ O que não fazer ​

  • Fazer commits diretos nas branchs develop, staging ou master.
  • Tentar pular a etapa de Staging para "ganhar tempo" em funcionalidades complexas.
  • Usar dados reais de pacientes em ambiente de Dev.