Pular para o conteúdo principal

Políticas e Boas Práticas de Desenvolvimento

Políticas adotadas pela H1TECH para desenvolvimento, versionamento, publicação e operação de soluções de software. O objetivo é garantir rastreabilidade, controle de qualidade, segurança operacional e continuidade.

Documento completo: Consulte o Caderno de Políticas de Desenvolvimento e Boas Práticas v2.0 (PDF) para detalhes expandidos, anexos e evidências.

Princípios Gerais​

  • Toda alteração de código deve ser versionada em repositório Git
  • Toda alteração relevante deve passar por pull request revisado por analista diferente do autor
  • Branches principais devem possuir proteção ativa no GitHub
  • Ambientes de desenvolvimento, QA e produção devem possuir separação lógica
  • Credenciais, tokens e chaves não devem ser armazenados em código-fonte
  • Ferramentas administrativas devem utilizar autenticação forte e 2FA sempre que disponível
  • Senhas SSH devem possuir rotação mensal, mínimo de 16 caracteres e composição alfanumérica com caracteres especiais
  • Acesso SSH por chave criptográfica deve ser priorizado sempre que aplicável

Versionamento em Git e GitHub​

Objetivo​

Garantir rastreabilidade de alterações, controle de histórico e recuperação segura do código-fonte.

Diretrizes​

  • Todo projeto deve possuir repositório Git definido
  • Branches principais devem possuir proteção ativa no GitHub
  • Commits devem seguir Conventional Commits
  • Alterações devem ser vinculadas a demanda, chamado, issue ou contexto técnico documentado

Evidências Recomendadas​

  • Print da proteção de branch
  • Histórico de commits
  • Pull requests aprovados
  • README, CHANGELOG ou documento de versionamento

Pull Request e Code Review​

Objetivo​

Reduzir risco de regressão, falhas de segurança e alterações não revisadas.

Diretrizes​

  • Todo PR deve ser revisado por pelo menos um analista diferente do autor
  • O revisor deve avaliar escopo, impacto, segurança, testes e compatibilidade
  • Comentários técnicos devem ser tratados antes do merge
  • Emergências devem ser documentadas posteriormente

Evidências Recomendadas​

  • Print de PR com aprovação
  • Print de comentário técnico
  • Print de regra exigindo review

CI/CD no GitHub​

Objetivo​

Automatizar validações, builds e publicações.

Diretrizes​

  • Pipelines devem ser mantidos em GitHub Actions ou equivalente
  • Pipelines devem executar etapas de lint, teste, build e deploy conforme o projeto
  • Falhas de pipeline devem impedir merge ou deploy quando configuradas como obrigatórias
  • Segredos devem ser armazenados em secrets, nunca em código

Evidências Recomendadas​

  • Print de workflow
  • Print de checks aprovados
  • Arquivo .github/workflows
  • Secrets mascarados

Versionamento MMP Documentado​

Objetivo​

Padronizar releases e controle de impacto.

Diretrizes​

  • Major para mudanças incompatíveis
  • Minor para novas funcionalidades compatíveis
  • Patch para correções e hotfixes
  • Publicações relevantes devem possuir resumo de mudanças

Evidências Recomendadas​

  • CHANGELOG
  • Tags e releases no GitHub
  • Package.json ou manifesto com versão

Testes Unitários e de Integração​

Objetivo​

Validar comportamento antes de publicação.

Diretrizes​

  • Projetos devem possuir testes unitários para regras críticas quando aplicável
  • Fluxos de integração devem ter testes automatizados ou coleções de validação
  • Endpoints sensíveis devem validar autenticação, payloads e erros esperados
  • Falhas detectadas em QA devem ser corrigidas antes de produção

Evidências Recomendadas​

  • Print de arquivos de teste
  • Relatório de testes
  • Coleção Postman/Insomnia
  • CI executando testes

Separação Lógica entre Ambientes​

Objetivo​

Evitar contaminação de dados e permitir homologação segura.

Diretrizes​

  • Ambientes dev, QA e produção devem ser separados por URLs, variáveis e credenciais
  • Credenciais de produção não devem ser usadas em desenvolvimento local
  • Deploy em produção deve ocorrer após validação
  • Variáveis de ambiente devem ficar fora do repositório

Evidências Recomendadas​

  • URLs distintas
  • .env redigido
  • Fluxo dev → QA → produção

Credenciais e Autenticação​

Objetivo​

Reduzir risco de acesso indevido.

Diretrizes​

  • 2FA deve ser habilitado nas ferramentas administrativas
  • Senhas SSH, quando usadas, devem rotacionar mensalmente e possuir no mínimo 16 caracteres
  • Chaves SSH devem ser priorizadas
  • Credenciais devem ser individuais, rastreáveis e revogáveis

Evidências Recomendadas​

  • Print de 2FA
  • Política de rotação
  • Configuração SSH por chave
  • Lista de usuários autorizados

Ferramentas de Proteção e Operação em Servidor​

FerramentaDescriçãoFunção
PM2Gerenciador de processos Node.jsManter aplicações rodando, monitoramento em tempo real, reinicializações automáticas
CertbotGerenciador de certificados SSL/TLSGeração e renovação automática de certificados Let's Encrypt para HTTPS
HTOPMonitor interativo do sistemaMonitoramento de RAM, CPU, swap e identificação de gargalos
NGINXServidor web e proxy reversoRoteamento por domínio, proxy reverso, HTTPS, headers e cache
UFWFirewall simplificado (Ubuntu)Controle de portas, políticas padrão de entrada/saída, logging

Uso na Política​

  • Aplicações Node.js devem ser executadas sob PM2 ou mecanismo equivalente
  • Aplicações expostas publicamente devem utilizar HTTPS/TLS com certificados válidos
  • Aplicações web e APIs devem ser expostas preferencialmente por NGINX
  • Servidores devem manter firewall ativo e liberar apenas portas necessárias

Backups e Continuidade Operacional​

Objetivo​

Garantir recuperação em caso de falhas.

Diretrizes​

  • Projetos e ambientes devem possuir estratégia de backup proporcional à criticidade
  • Backups devem possuir periodicidade definida
  • Backups devem ser armazenados em local protegido
  • Restaurações devem ser testadas quando o ambiente for crítico
  • Backups e logs devem respeitar política de retenção
  • Backups não devem conter segredos expostos sem proteção

Escopo de Backups​

Código-fonte, arquivos de configuração, bancos de dados, arquivos de aplicação, logs relevantes e documentação operacional.

Infraestrutura Hostinger​

Quando a solução for hospedada em VPS Hostinger, a infraestrutura do provedor complementa (mas não substitui) as políticas internas:

  • Firewall VPS — regras para filtrar tráfego IPv4 e IPv6
  • Proteção anti-DDoS — medidas para reduzir riscos de indisponibilidade
  • Boas práticas de VPS — firewall, atualizações, proteção de SSH, restrição de serviços públicos
  • Medidas gerais de segurança — documentação institucional de segurança do provedor

Referências Oficiais​

Documento Completo​

Para detalhes expandidos, anexos com prints de testes, NGINX, firewall, CI/CD, pull requests e 2FA, consulte:

📄 Caderno de Políticas de Desenvolvimento e Boas Práticas H1TECH v2.0

Versão 2.0 • Julho de 2026 • Aplicável a aplicações, APIs, projetos e ambientes mantidos pela H1TECH