Baixado 20 vezes
![Integração Antecipada de
Código
- ambiente de desenvolvimento local +
DEV0[1-4] + QA1 + Staging + PROD
- estava se tornando comum quebrar o
código do colega ao lado e só perceber
isso no último momento
15](https://image.slidesharecdn.com/scrumgathering4x3-140904203615-phpapp02/85/Scrum-Gathering-Rio-2014-15-320.jpg)
Carregado porVictor Pantoja
Scrum Gathering Rio 2014
O documento discute a integração entre equipes e os desafios enfrentados na aplicação do Scrum no desenvolvimento de sites no Brasil, especialmente no contexto do globoesporte.com e sportv.com. O autor, Victor Pantoja, compartilha experiências sobre a importância da comunicação e da integração contínua de código para evitar problemas e melhorar processos. Ele enfatiza que a colaboração e a adaptação constante são fundamentais para o sucesso em ambientes ágeis.
Scrum Gathering Rio 2014
- 1. Integração entre timese o desafio de desenvolver uma aplicação Scrum Gathering Rio 2014
- 2. 2 Victor Pantoja Engenheiro Eletrônico e de Computação pela UFRJ e mestre em Informática pela PUC-Rio, possuo mais de 9 anos de experiência desenvolvendo grandes sites focados no usuário. Scrum Master da área de aplicações móveis (before it was cool) de 2007 a 2008. Atualmente, sou desenvolvedor web sênior no globoesporte.com, o maior site de esportes do Brasil e o site oficial da Copa do Mundo FIFA Brasil 2014.
- 3. Background 4 TimesÁgeis com 3 a 4 dev + 1 Infra + 1 DBA + SM + 1 PO Python / Django 3
- 4. Alguns números Visitantesúnicos: 20,7 milhões por mês Visitas: 215 milhões por mês 8 milhões de visitas por dia! 4
- 5. Cenário 2011 5 1 time trabalhando no globoesporte.com e, depois, no sportv.com
- 6.
- 7. Mudanças 7 1time trabalhando no globoesporte.com + Combate + Eu Atleta ao mesmo tempo
- 8. Mudanças 8 1time trabalhando no globoesporte.com 1 time trabalhando no SporTV 1 time trabalhando em Classificação / Tabelas O mesmo código ao mesmo tempo!
- 9.
- 10.
- 11.
- 12. Diálogo Reuniões periódicaspara: -falar sobre o que cada time está fazendo -identificar pontos de sobreposição de trabalho -discutir novas tecnologias -melhorar nosso processo 12 de trabalho
- 13. Segregação do Código -havia uma quantidade (pequena) de bugs introduzidos em código alheio -isolamento do código legado Isolamento do código através de apps django 13
- 14. Integração Antecipada de Código 14 Objetivo: descobrir o problema antes que ele chegue em produção
- 15. Integração Antecipada de Código - ambiente de desenvolvimento local + DEV0[1-4] + QA1 + Staging + PROD - estava se tornando comum quebrar o código do colega ao lado e só perceber isso no último momento 15
- 16. Integração Antecipada de Código - perguntar se alguém usa certo trecho de código se mostrou bastante ineficiente pelo tamanho do projeto - solução: ambiente único de integração continua executando a última versão de todas as apps - coordenação dos releases 16
- 17. Isolamento dos Testes - o objetivo é garantir que o código da app está bem isolado - isolamento de testes através de um settings no projeto que faz referência apenas para a app em questão - grau de acoplamento deve ser visto caso a caso. Utilizar os recursos da 17 própria linguagem para isso é uma boa abordagem
- 18. Mudar Tudo Novamente! Mude sempre! 18
- 19. Palavra Final 19 Comunicação é a chave!
- 20.
Notas do Editor
- #3 Todos os 9 anos na globo.com. Já fiz muito caso de uso e de testes. E diagramas enormes no MS Project com tudo direitinho: custos, caminho crítico…
- #4 Acho que todos sabem que trabalhamos com Scrum a uns 7 anos. Éramos 4 times. Agora apenas 3. Criativamente chamados de esportes1, 2, 3 e 4. Tem gente que chama de alfa, beta… mas não somos criativos a esse ponto.
- #5 Mas antes, alguns dados sobre o globoesporte.com para vocês entenderem o tamanho do problema!
- #6 Apenas um time dedicado ao globoesporte.com. Esse mesmo time desenvolveu o SporTV.
- #7 Timelapse esportes1
- #8 Esse único time começa a tocar mais de um projeto em paralelo
- #9 3 times se unem para atualizar a interface do globoesporte.com + sportv.com
- #10 Um time pode introduzir bug no código de um outro com alguma facilidade… é apenas uma questão de tempo
- #11 Precisa ser assim?
- #12 Como fazer essa galera remar junta?
- #13 Se nessa reunião fosse identificado que dois times estavam atuando em elementos parecidos ou que pudessem aproveitar algo já feito do outro, isto deveria ser discutido. Nestas reuniões também discutimos assuntos de nosso interesse: algo que tenhamos pesquisado ou alguma tecnologia que gostaríamos de experimentar.
- #14 Uma alteração no comportamento de um método podia quebrar um outro em um ponto de código que jamais suspeitaríamos Decidimos usar a linguagem de programação (Python) e o framework Django a nosso favor e optamos por quebrar o globoesporte.com em dezenas de apps isoladas que falariam entre si apenas por interfaces. Ou seja: nenhum método não exposto poderia ser usado e, se fosse usado, seria por conta e risco do desenvolvedor.
- #16 Na globo.com, como na maioria das empresas de TI, temos nosso ambiente de desenvolvimento local e os ambientes de testes antes de chegarmos ao ambiente de produção. Desenvolver na própria máquina é ótimo! Tudo funciona da maneira projetada e quase nada dá errado. Daí, seu código chega em produção e (oh!) não funcionou. Pior, quebrou o código do seu colega do lado que trabalha em outro time e desenvolveu uma funcionalidade que você nem sabia e que estava usando este mesmo trecho de código que você alterou. O que aconteceu neste caso foi a integração tardia do código.
- #17 Decerto, a maneira mais rápida de resolver problemas como o descrito no parágrafo anterior é perguntando se alguém usa esse método. Porém, em um projeto grande, como o globoesporte.com, em que dezenas de apps são mantidas e evoluídas por vários times, perguntas desse tipo rapidamente podem se transformar em uma inspeção visual de código a procura de pontos que utilizem esse código. Os times do globoesporte.com decidiram automatizar esse procedimento de duas formas: ambiente único integração contínua e criação de um ambiente de testes com todo o código mais recente instalado. A primeira forma significa simplesmente que teríamos um CI único e que utilizaríamos o Jenkins para tal. Dessa forma, todos os testes de todos os projetos seriam executados juntos e ficariam sempre visíveis. A segunda, ambiente único de testes, significa que toda alteração em que houvesse dúvida, ou certeza, de que haveria impactos em outros pontos deveria ser testada frente aos branches de desenvolvimento das demais apps. Isso feito, era preciso também coordenar as subidas para produção. Se um time tem alguma subida planejada, ele deve avisar aos demais. Além disso, se um time estiver pensando em realizar uma subida, deve consultar os demais. Essa integração, por ser mais simples, é feita utilizando nosso bom e velho email corporativo ou, melhor ainda, falando com o colega do lado.
- #18 Após passar todo a apresentação falando sobre integração, esse quarto passo pode parecer contraditório. Porém, antes de buscar resolver problemas de integração é bom ter certeza de que o código de sua app está bem isolado do de outras. Essa verificação poder ser facilmente feita através da execução isolada de testes funcionais. Como utilizamos Django, a forma que encontramos foi termos um settings para cada app que seria usado nos testes isolados e que conteria apenas as dependências básicas no atributo INSTALLED_APPS. Claro que o grau de acoplamento vai depender do objetivo e funcionalidades da sua app. Por exemplo, temos uma app chamada globoesporte-core que, como o nome sugere, possui todos os métodos comuns a várias apps. Dessa forma, nossa app “jogo” depende fortemente da app “core”. Porém, essa relação é assimétrica: a app “core” não depende da app “jogo”. Imagine agora outra app chamada “materia”, contendo o código necessário para termos notícias no globoesporte.com. A princípio, esta app não deveria depender de “jogo” mas existe a crônica de um jogo que nada mais é que uma matéria e essa dependência passa a existir. O interessante neste caso é reduzir ao máximo o acoplamento entre elas. A forma de se fazer isso depende da linguagem de programação e cada uma tem sua implementação. Em Java, por exemplo, isso pode ser feito através de métodos públicos e privados. Em Python, o desenvolvedor pode expor apenas os métodos desejados através do arquivo __init__.py.
- #19 Mude sempre! Adeque-se a novas formações de times e a novos conceitos. A evolução da tecnologia nos mostra diariamente que o que funcionou hoje pode não funcionar tão bem amanhã.
- #20 Para os que chegaram até aqui! Acredito que nada do que foi dito aqui é novidade. Não reinventamos a roda, apenas aprendemos a trabalhar em conjunto com os demais times através do diálogo constante.
- #21 Perguntem por favor! Quem tiver com vergonha, nossos twitters são...