Nessa apresentação, eu falo sobre como 3 times (cerca de 12 desenvolvedores) conseguem trabalhar na mesma básica de código sem gerar bugs e entregar o globoesporte.com
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
7. Mudanças
7
1 time trabalhando no
globoesporte.com +
Combate + Eu Atleta ao
mesmo tempo
8. Mudanças
8
1 time trabalhando no
globoesporte.com
1 time trabalhando no
SporTV
1 time trabalhando em
Classificação / Tabelas
O mesmo código ao mesmo
tempo!
12. Diálogo
Reuniões periódicas para:
-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
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…
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.
Mas antes, alguns dados sobre o globoesporte.com para vocês entenderem o tamanho do problema!
Apenas um time dedicado ao globoesporte.com. Esse mesmo time desenvolveu o SporTV.
Timelapse esportes1
Esse único time começa a tocar mais de um projeto em paralelo
3 times se unem para atualizar a interface do globoesporte.com + sportv.com
Um time pode introduzir bug no código de um outro com alguma facilidade… é apenas uma questão de tempo
Precisa ser assim?
Como fazer essa galera remar junta?
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.
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.
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.
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.
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.
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ã.
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.
Perguntem por favor! Quem tiver com vergonha, nossos twitters são...