Processo de trabalho com o GIT

Metodologia de trabalho com branches no GIT utilizado pelo time de desenvolvimento da F.biz.

Transcript

1. Processo de trabalho no GIT Marcelo Miranda Carneiro 25/09/2014
2. Visão geral • Vantagens de se definir uma estratégia de branches; • Estratégia adotada pela F.biz; • Processo de criação e manutenção dos branches; • Como acontecerá a implementação; • Um pouco de código; • Próximos passos; 01 F.biz | COMPANY CONFIDENTIAL
3. Não precisa ficar “muito bom”, apenas “bom” M.Z. — Brasil, 2008
4. Não precisa ficar “muito bom”, apenas “bom” M.Z. — Brasil, 2008
5. Devemos fazer o trabalho da melhor forma possível
6. Problema
7. Problema Pontos fracos do modelo atual: • organização: não existe unidade no time sobre “quando” e “como” criar um branch; • flexibilidade: mudança durante o desenvolvimento gera problema na administração do repositório; • comunicação: equipe não sabe da existência ou objetivo dos branches. 02 F.biz | COMPANY CONFIDENTIAL
10. Pontos fracos • Mudanças inesperadas tem impacto muito negativo; • Aumenta chances de erros impeditivos causados por outros desenvolvedores; • Engessa a atualização de código em produção; • Esse é o pior modelo e mesmo assim a maioria dos projetos estão sem branches.
13. Pontos fracos Temos apenas 1 linha de desenvolvimento: 1. projeto é lançado; 2. alguém faz uma nova implementação no m a s t e r; 3. repositório perde sincronia com produção; 4. bug de produção vai dar mais trabalho para implementar.
14. Gitflow
15. Gitflow “Gitflow”, é uma forma de criar e organizar os branches, criado pelo Vincent Driessen: • post na nvie.com - http://goo.gl/GDaF • tutorial na Atlassian - http://goo.gl/1cVnDG A F.biz utiliza uma variação do Gitflow, adaptado ao dia-a- dia da agência. 03 F.biz | COMPANY CONFIDENTIAL
16. “master” e “working” Separar a linha de “produção” e “desenvolvimento”: • branch m a s t e r deve ser um espelho de produção; • branch w o r k i n g contém o desenvolvimento da versão atual; • é o espelho de “homologação”, apenas código pronto para teste da área de Projetos; • nome “master” e “working” são reservados; • ambos apenas recebem operações de merge. 04 F.biz | COMPANY CONFIDENTIAL
18. “features” Separar programação dos módulos da linha principal: • implementações em branches próprios (“feature branches”); • nomenclatura do branch segue regra 0 - 9 a - z - _: • - para separação de palavras; • _ para indicar branch pai no prefixo; • na finalização (testado e integrado) reintegra com w o r k i n g; • excluído apenas quando reintegra com m a s t e r; 05 F.biz | COMPANY CONFIDENTIAL
20. “hot-fixes” Ajustes, alterações, implemetações, etc. na linha de desenvolvimento de produção: • acontecem em “hotfix branches”; • criados a partir de m a s t e r e recebem prefixo m a s t e r _; • após teste e aprovação, são reintegradas no m a s t e r e w o r k i n g; 06 F.biz | COMPANY CONFIDENTIAL
23. Múltiplos “working” Projetos com múltiplas linhas de desenvolvimento podem conter diversos working branches: • w o r k i n g - aceite.fbiz.com.br/cliente • w o r k i n g - f a s e 2 - aceite.fbiz.com.br/cliente-fase2 Todos os branches que não forem w o r k i n g * ou m a s t e r * são criados a partir do “working” principal. 07 F.biz | COMPANY CONFIDENTIAL
24. Indicação de branch “pai” Casos onde o nome do branch indica o seu criador: • feature em casos de múltiplos “working”, apenas as variações: • w o r k i n g - f a s e 2 ← w o r k i n g - f a s e 2 _ q u i z • branch que nasce de uma feature: • q u i z ← q u i z _ r e f a c t o r y e w o r k i n g - f a s e 2 _ q u i z ← w o r k i n g - f a s e 2 _ q u i z _ r e f a c t o r y • hot-fix sempre nasce do “master”: • m a s t e r _ b u g - q u i z 08 F.biz | COMPANY CONFIDENTIAL
25. Criação de tags
26. Criação de tags Tag são criadas (“major.minor.fix”) sempre que produção for atualizado: • major: reskin, mudança de estrutura, novo site; • minor: novas features, nova mecânica ou área, mudança de mecânica ou área, etc; • fix: ajustes de erros em código ou conteúdo. 09 F.biz | COMPANY CONFIDENTIAL
27. Criação de tags Tags devem conter descrição resumida do que foi feito naquela publicação: • 1 . 0 . 0: primeira versão em produção; • 1 . 0 . 1: lay-out quebrado no quiz; • 1 . 1 . 0: página de vencedores; 10 F.biz | COMPANY CONFIDENTIAL
29. Comunicação
30. Comunicação Wiki do Bitbucket será o “hub” do projeto: • Na criação de um “feature branch”, atualizar com nome e objetivo; • Antes de criar, verifique se já está sendo trabalhado. • Na reintegração com m a s t e r, remover da wiki; • Teremos um changelog com todas as tags de publicação apontando os cards do Trello; 11 F.biz | COMPANY CONFIDENTIAL
32. Comunicação Convite para implementação de ferramentas nos projetos: • https://fbiz.slack.com/ - substituto ao e-mail, integrações com Bitbucket, Trello, HTTP Post, etc; • http://appear.in/ - video-conferências dinâmicas com screenshare; • https://ngrok.com/ - túnel entre sua máquina e internet; 12 F.biz | COMPANY CONFIDENTIAL
33. Implementação
34. Implementação • É responsabilidade de todos da equipe seguir e disseminar as práticas; • No início, coordenadores discutirão sobre branches; • branch virá sugerido no card do Trello. • No Trello, teremos uma checklist para publicação: • teste, remoção de branches, criação de tag, atualização da wiki, etc. 13 F.biz | COMPANY CONFIDENTIAL
36. Na prática
37. Criando branches locais Antes de fazer uma nova implementação, verifique na wiki se o branch já existe ou crie um novo. Branch q u i z existe remoto: $ g i t c h e c k o u t q u i z Branch q u i z precisa ser criado “do zero”: $ g i t c h e c k o u t - b q u i z w o r k i n g 14 F.biz | COMPANY CONFIDENTIAL
38. Atualizando o branch remoto Para atualizar o código no servidor: $ g i t p u s h o r i g i n q u i z Quando o w o r k i n g for atualizado: $ ( q u i z ) g i t p u l l o r i g i n w o r k i n g 15 F.biz | COMPANY CONFIDENTIAL
39. Atualizando o “working” Quando o trabalho do “feature branch” estiver finalizado e testado (pronto para homologação): $ ( q u i z ) g i t c o w o r k i n g $ ( w o r k i n g ) g i t m e r g e q u i z - - n o - f f • Opção - - n o - f f garante que não haverá “fast-forwarding” e que o branch seja indicado no histórico como uma linha separada de desenvolvimento. 0 1 . 0 2 . 16 F.biz | COMPANY CONFIDENTIAL
40. Atualizando o “working” Excluir os branches (“local” e “remote”): $ g i t b r a n c h - d q u i z $ g i t p u s h o r i g i n : q u i z Atualizar o código remoto: $ g i t p u s h o r i g i n w o r k i n g 0 1 . 0 2 . 17 F.biz | COMPANY CONFIDENTIAL
41. Criando tags Quando publicarmos uma versão do projeto: $ ( m a s t e r ) g i t t a g - a " 1 . 0 . 0 " - m " p r i m e i r a v e r s ã o e m p r o d u ç ã o " Enviando as tags para produção: $ g i t p u s h o r i g i n - - t a g s 18 F.biz | COMPANY CONFIDENTIAL
42. TL;DR;
43. TL;DR; • m a s t e r é produção, w o r k i n g é homologação; • Apenas operações de merge em m a s t e r e w o r k i n g; • w o r k i n g apenas com - - n o - f f; • “Feature branches” a partir de w o r k i n g; • Integrações completas no mesmo branch, ex.: q u i z; • Inicialmente - sugestão de branches no pedido do job; 19 F.biz | COMPANY CONFIDENTIAL
44. TL;DR; • “Feature branches” só são reintegrados quando testados e finalizados; • Atualizar wiki na criação e exclusão de branches; • Criação de tag (major.minor.fix) quando publicar; • Atualização no changelog com o link do Trello; • Estrutura deve ser aplicada a partir de agora. 20 F.biz | COMPANY CONFIDENTIAL
45. Vantagens • Incentivo à separação de módulos (escalabilidade); • “Escopo” de desenvolvimento; • Maior controle e flexibilidade — redução de impacto na mudança de plano / linha de desenvolvimento; • Criação de histórico dos deploys; • Histórico mais organizado — primeiro passo para um code-review eficaz; 21 F.biz | COMPANY CONFIDENTIAL
46. Próximos passos
47. Próximos passos • Capacitação da equipe para melhor utilização do GIT; • Utilização do slack por projeto + integração bitbucket; • Code-review interno e externo com pull requests; • Validação inicial automatizada; • Utilização de issue tracker para QA de desenvolvimento; 22 F.biz | COMPANY CONFIDENTIAL
48. A WPP Company / thank you