É um dos princípios de Integração Contínua ▪ Após cada commit, o build pipeline é acionado: testando, deployando, testando de novo… ▪ Modelo de branching para desenvolvimento de software ▪ Feature Branches são branches que duram todo o tempo de desenvolvimento de cada funcionalidade ▪ Long-lived branches == merge hell
Horizonte) ▪ Desenvolvedores com diferentes experiências ▪ Muitas tecnologias no mesmo projeto ▪ Equipe de 20 desenvolvedores ▪ Projeto com domínio muito complexo ▪ Projeto com riscos de alto impacto
Consolidar uma visão técnica do time sobre a plataforma ▪ Impulsionar discussões técnicas ▪ Compartilhar conhecimento ▪ Impulsionar cultura Open Source
convidamos a equipe a uma discussão, basicamente, o code review. ▪ Se necessário, a partir dos comentários, realizamos as mudanças. ▪ Depois das modificações, abrimos um Pull Request. ▪ Para qualquer modificação, criamos uma nova branch. ▪ Se o build dessa branch está verde, verificamos os approves. ▪ Fazemos merge no master.
Requests abertos por muito tempo, se a discussão ficar longa ou difícil, agende um dev-huddle. O code review não deve deixar a equipe bloqueada. ▪ Quanto maior o PR, mais difícil de revisar e pedir feedback. ▪ Escreva uma descrição clara e dê um contexto sobre as modificações • Referências externas ajudam!
littlejuh
negi111111
yoshidashingo
sadnessojisan
sugamasao
stajima
tohutohu
tkikuchi
akexorcist
salaboy
chanyou0311
tsumita
nikinusu
stephaniewalter
jponch
philnash
chriscoyier
mza
bkeepers
destraynor
denniskardys
shlominoach
chrisshort
lara
mojombo
![DÚVIDAS? Juliana Fernandes [email protected] Twitter: @littlejuh_ Github: littlejuh](https://files.speakerdeck.com/presentations/27ec15233c834695a3a8f7d526bc5758/slide_11.jpg){kind=link}