Move fast and break things? Uma análise sobre a adoção de releases rápidas no projeto Firefox

Apresentado no JusBrasil Tech Talks em 2014-10-31

Transcript

1. Move fast and break things?
 Uma análise sobre a adoção de 
 releases rápidas no projeto Firefox Rodrigo Rocha G. e Souza <rodrigorgs@gmail.com> 2014-10-31 JusBrasil Tech Talks
2. Sobre mim Programador desde 1995 Doutorando em Ciência da Computação na UFBA desde 2010 Analista de TI na UFBA desde 2012 Músico amador
3. Referências
4. Firefox
5. Contexto histórico 2008: Chrome
 (mais competição) 2010: HTML5
 (novos requisitos) 2011: Firefox for Android
 (novas plataformas) Lança uma nova versão quando ela estiver pronta: 2004 — 1.0 2006 — 2.0 2008 — 3.0 2011 — 4.0
6. Resposta da Mozilla: releases rápidas • Lança uma nova versão a cada 6 semanas • Funcionalidades chegando mais cedo para os usuários!
7. Problemas • Notificações chatas! • Quebrou os plugins! • Usuários corporativos querem estabilidade!
8. Ponto de vista técnico Que ferramentas e processos a Mozilla usa? O que precisou mudar pra viabilizar uma release a cada 6 semanas?
9. Bugzilla Buildbot
10. anexa patch revisa patch faz push para repo
11. compila e roda testes fixed! testes manuais
12. Integração de código • Faz o push no Mozilla Central (m-c) • Espera 4–6 horas pra fazer o build e rodar os testes • Se quebrar o build, quebrar os testes etc.: • o repositório é fechado
 (não aceita mais pushes) • você tem que reverter (back out) • se demorar pra reverter, outros devs podem se basear no seu código quebrado
14. O que 
 mudou?
15. Repositórios de integração • 2011: surgimento dos repositórios de integração • Você faz o seu push para o repositório de integração e vai pra casa Fonte: https://wiki.mozilla.org/Tree_Rules
16. Integração em detalhes m-i m-c só código testado! dev1 dev2 backout build
 failed! merge merge ~ 24 h
17. Xerife • Acompanha os builds e faz backout dos commits que quebram os builds. • Após um build bem-sucedido, faz merge e marca os bugs como FIXED. • Devs se alternam no papel de xerife.
18. faz push para repo fixed!
20. Será que a Mozilla conseguiu se mover mais rápido sem quebrar as coisas?
21. Quantos % dos bug fixes
 são revertidos (backed out)?
 
 Esse número aumentou com as releases rápidas?
22. Dados 3.5 3.6 4.0 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 2009-06-30 2011-03-22 2011-06-21 2013-09-17 traditional releases rapid releases with integration repositories versions release dates rapid releases (transition) Mais de 40 mil bugs corrigidos em pouco mais de 4 anos
23. 2010 2011 2012 2013 0.00 0.02 0.04 0.06 0.08 0.10 Overall backout rate time O processo está mais instável?
24. faz push para repo fixed! backout tardio backout cedo ex.: build/teste quebrou ex.: falhou em teste manual
25. 2010 2011 2012 2013 0.00 0.02 0.04 0.06 0.08 0.10 Early and late backout rate time early backout late backout tardio cedo
26. “our automated testing has improved considerably since [release] 3.5.
 A number of memory leak finding tools have been integrated into our test environments that are improving our early catch-rate” Por que mais backout cedo? Evolução das ferramentas de teste automatizado:
27. Por que mais backout cedo? Repositórios de integração e cultura de backout: “in the ‘old days’, you were expected to have built, tested,
 done a Try build, etc. before the patch landed” “Breaking it [i.e., m-i] rarely is ok. Never breaking the tree means you're running too many tests before landing [i.e., pushing].”
28. Impactos sobre o desenvolvimento “I'd say amount of time spent testing patches before landing, and
 amount of time wasted with trees closed due to bustage, were reduced.”
29. Impactos sobre o desenvolvimento • Backouts tardios são piores: • Mais tempo passou desde o commit, demora mais pra se lembrar do contexto • Significa que um commit defeituoso foi usado como base para outros commits • O commit definitivo vai demorar mais pra chegar ao usuário
30. Conclusão • Análise ingênua: backout aumentou, processo está mais instável! • Realidade: Firefox está fazendo backout mais cedo • Isso ocorre graças e melhorias na automação de testes e a repositórios de integração gerenciados por xerifes • Além disso, é preciso menos esforço pra testar patches • Resultado: todo dia tem código relativamente estável (cf. chemspill)
31. Links relacionados • Firefox Release Engineering (AOSA book): http://aosabook.org/en/ ffreleng.html • Mozilla Release Processes: http://mozilla.github.io/process-releases/ • Mozilla Release Process From the Point of View of a Data Scientist: http:// rodrigorgs.github.io/blog/2013/09/08/mozilla-process/ • RELENG 2014 (workshop): http://releng.polymtl.ca/RELENG2014/html/ program.html (ver video de Chuck Rossi, do Facebook) • Spotify Engineering Culture (Part 1): https://labs.spotify.com/2014/03/27/ spotify-engineering-culture-part-1/ (fala um pouco sobre release engineering)