Desenvolvimento

Ξ Deixe um comentário

Integração entre times e o desafio de desenvolver uma aplicação

publicado por Victor Pantoja

Integração entre times e o desafio de desenvolver uma aplicaçãoIntegração entre times é um assunto bastante discutido aqui na globo.com. Temos diversos produtos e dezenas de times trabalhando de forma isolada nesses produtos. Quando entrei no portal globoesporte.com, em 2011, éramos um time scrum recém-formado com 3 desenvolvedores, um SM, um PO e uma dupla de UX. Na época, nenhum dos desenvolvedores jamais havia trabalhado no portal e sequer havíamos mexido com o framework por trás dele. Apenas esse time estava encarregado de manter e evoluir o globoesporte.com. Havia ainda um agravante: recebemos um código legado construído sobre um framework quando este ainda estava no início de seu desenvolvimento. Os testes eram escassos e não sabíamos o impacto das alterações que fazíamos.

Com o passar do tempo e com o amadurecimento e maior integração dos desenvolvedores do nosso time, passamos a ter ownership do projeto. Conhecíamos cada linha de código e sabíamos exatamente para que cada método servia e onde ele era usado. Definimos muitos padrões de escrita de código e também de testes sem consultar os demais times da área de esportes que cuidavam dos demais projetos como o Cartola FC e o Futpedia.

Esse cenário começou a mudar quando surgiu a necessidade de reconstruir o globoesporte.com e atualizar sua linguagem visual e editorial. Diversos novos tipos de conteúdo seriam agregados ao portal. Surgiram sites como o Eu Atleta, o Combate e o redesenho do SporTV. Havia em nossa direção as Olimpíadas de Londres 2012 e do Rio de Janeiro, em 2016. Havia também a primeira Copa do Mundo FIFA de Futebol aqui no Brasil depois de 64 anos. Era impossível que apenas um time fosse responsável por tudo isso. Passamos a ser 4 times trabalhando juntos no globoesporte.com e no Tempo Real. O meu time, denominado esportes 1, tinha a missão de guiar o desenvolvimento, uma vez que possuíamos uma imensa bagagem adquirida em quase 3 anos de desenvolvimento do portal. Porém, cada time já estava trabalhando junto havia algum tempo e possuía seus próprios padrões e cultura de testes, autonomia de deployment para os seus ambientes de desenvolvimento e de produção e também seus problemas e suas verdades absolutas.

Como realizar a integração desses times? Como garantir que o código escrito por um não quebrasse o do outro uma vez que a integração seria inevitável? Os padrões que impúnhamos não eram, com toda a razão, aceitos pelos demais e sentíamos que faltava diálogo. A falta de conversa foi declarada a grande vilã e o primeiro problema de integração que atacaríamos.

PRIMEIRO PASSO DA INTEGRAÇÃO: DIÁLOGO

Decidimos que faríamos reunião periódicas e que a freqüência dependeria da necessidade de se passar conhecimento. No começo, como tudo era novo para todos, optamos pela reunião semanal. Nestas reuniões, falávamos um pouco sobre o que cada time estava fazendo e tentávamos identificar possíveis problemas de integração, como pontos de sobreposição de trabalho tanto a nível de componente quanto de métodos necessários para se construir um certo elemento da página. Um componente (ou elemento) de escalação de um time. 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.

SEGUNDO PASSO: SEGREGAÇÃO DO CÓDIGO

Pela falta de integração, passamos a introduzir uma quantidade pequena, porém significativa, de bugs no código de outros times. Uma alteração no comportamento de um método podia quebrar um outro em um ponto de código que jamais suspeitaríamos. Havia ainda muito código legado anterior ao meu time e ainda mais código legado escrito por nós mesmos durante nosso amadurecimento. 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.

TERCEIRO PASSO: INTEGRAÇÃO MAIS CEDO DO CÓDIGO

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.

QUARTO PASSO: EXECUÇÃO ISOLADA DOS TESTES DAS APPS

Após passar todo o artigo 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.

QUINTO PASSO: MUDAR TODO O PROCESSO NOVAMENTE!

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ã.

[Crédito da Imagem: Integração entre times – ShutterStock]

Autor

Engenheiro eletrônico e de computação pela UFRJ e mestre em informática pela PUC-Rio, atuo desde 2005 como engenheiro de software na globo.com tendo desenvolvido aplicações web de alta performance e escaláveis como o globoesporte.com e também o fanstasy game Cartola FC.

Victor Pantoja

Comentários

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes