Processo FrontEnd - Reloaded

gistfile1.md

Processo de desenvolvimento FrontEnd Terra - Reloaded

Problemas atuais

• Solução obsoleta
  A solução atual foi baseada em um problema existente na época (OMG ATM).
  Essa solução foi crucial para chegar onde chegamos, mas já está na hora de evoluí-la.
  São muitos jobs no Jenkins com uma execução kinda silly, que varrem todos os projetos, tornando a solução nada escalável.

• Slowwwwwwww
  Devido ao problema citado acima, os processos de build são extremamente lentos, e a cada novo projeto criado, a lentidão aumenta.

• Muitos passos para configurar 1 projeto
  A solução atual exige a criação de 2 novos jobs no Jenkins para cada projeto. Além disso, é necessário alterar mais 2 jobs para o processo funcionar completamente.

• Contar com o bom senso (AHHAHA)
  O processo atual não exige alguns passos básicos para validação da solução criada, fazendo com o que o bom senso do desenvolvedor seja usado, e na maioria dos casos isso não acontece.
  Ex: Para testar a solução em um ambiente integrado, antes de ir para produção, o desenvolvedor precisa acessar esse ambiente e validar manualmente a solução.

• Processo facilmente burlável
  Hoje, qualquer desenvolvedor pode burlar o processo. Desativando tasks do Grunt, ou mesmo fazendo "assert:true"

Premissas

• Separar devDependencies de dependencies no package.json
• Fazer melhor uso do npm
• Usar somente o npm para as tasks de builds, teste, etc.
• Preview mode explicíto default
• Ter menos jobs no Jenkins
• Desativar o job dispatcher(responsável por varres todos os projetos)
• Eliminar scripts mágicos e dependências obscuras
• Criar scripts novos e mais simpels para esse processo (fácil manutenção pela equipe)
• Fazer o processo de build/deploy ser passivo (Abre PR > Dispara o Job)
• Tornar o processo mais simples
• Se possível tirar o passo do SVN(sim, ainda existe em supweb) na ponta do build

Novo fluxo

• Dev abre um pull-request para uma nova branch
  • Bottr entra em ação, interage no pull-request, faz o build e coloca em HLG
• Dev aprova o merge (da nova branch) no Github
• Bottr faz o build e coloca em PREV (fazendo um pull-request para a master branch)
• Dev aprova o merge na master branch
• Bottr coloca em PRD

Benefícios

• Deploy muito mais rápido
• Build muito mais rápido
• Processo escalável
• Processo mais fácil de entender
• Melhor validação
• Melhor controle dos projetos