É 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
hakubishin3
nenonaninu
knih
fujiwara3
mochizuki875
segavvy
coosuke
muziyoshiz
matthewlujp
murashotaro
yokawasa
.png){kind=icon}
pharma_x_tech
stephaniewalter
palkan
sugarenia
bkeepers
sonatard
paigeccino
lara
iamctodd
tenderlove
paulrobertlloyd
thekraken
productmarketing
![DÚVIDAS? Juliana Fernandes [email protected] Twitter: @littlejuh_ Github: littlejuh](https://files.speakerdeck.com/presentations/27ec15233c834695a3a8f7d526bc5758/slide_11.jpg){kind=link}