Um recente artigo acadêmico publicado pelo prof. dr. Feitelson da Hebrew University, por Eitan Frachtenberg, pesquisador no Facebook, e por Kent Beck (que também está fazendo alguma coisa no Facebook), descreve a abordagem do Facebook para desenvolver e colocar em funcionamento o seu software frontend. Apesar de que seria muito mais interessantes entender como o desenvolvimento backend é feito (é lá que a maior parte do trabalho é realizado para manipular centenas de milhões de usuários), há algumas coisas no artigo que valem a pena saber.

Continuous Deployment no Facebook não é Continuous Deployment

Em vez de planejarem o trabalho em projetos ou dividir o trabalho em Sprints, desenvolvedores do Facebook fazem a maior parte do trabalho em pequenas mudanças independentes que são lançadas frequentemente. Isso faz sentido no modelo de negócio online do Facebook, no qual todos estão ajustando constantemente a plataforma e tentando novas opções e aplicativos em diferentes comunidades de usuários e vendo o que funciona. Isso se deve à arquitetura que permite que mudanças tão pequenas e independentes possam na verdade ser feitas de maneira independente e barata.

O Facebook diz que eles seguem o continuous deployment, mas não se trata de continuous deployment da forma que IMVU tornou popular, na qual todas as mudanças são enviadas aos clientes imediatamente, ou mesmo como uma empresa como a Etsy faz continuous deployment.

No Facebook, código pode ser lançado duas vezes por dia, mas isso é normalmente feito principalmente para correções de bugs e código interno. Código de produção novo é lançado uma vez por semana: milhares de mudanças de centenas de desenvolvedores são empacotadas no domingo pela pequena equipe de “release” que eles possuem, passadas em testes automatizados de regressão e colocados em funcionamento na terça-feira, caso os desenvolvedores que contribuíram com as mudanças estiverem presentes. Engenheiros de “release” avaliam o risco das mudanças baseados no tamanho delas, na quantidade de discussão feita na revisão do código (que é gravada através de um sistema interno de revisão de código) e no “push karma” de cada desenvolvedor: em quantos problemas eles viram no código desse desenvolvedor anteriormente.

Uma ferramenta chamada “Gatekeeper” (porteiro) controla que recursos estarão disponíveis para quais clientes de forma a suportar dark launching, e todo código é disponibilizado incrementalmente –  colocado em “staging”, depois para um grupo de usuários, e assim por diante. Mudanças podem ser desfeitas caso seja necessário – individualmente, ou como último recurso, todo um release de código. Entretanto, como em muitas empresas do Vale do Silício que adotam devops, eles seguem o lema “homens de verdade só vão para frente”.

Propriedade de código

Uma chave para a cultura do Facebook é que os desenvolvedores são individualmente responsáveis pelo código que eles escrevem, para testá-lo e suportá-lo em produção. Isso está refletido no modelo de propriedade de código que eles adotam:

Desenvolvedores precisam dar suporte para o uso operacional de seu código – uma combinação que vem sendo chamada de “devops”. Isso incentiva a escrita de código de qualidade e testes extensivos. O risco pessoal dos desenvolvedores em manter o sistema funcionando bem complementa os procedimentos de engenharia e permite que o sistema mantenha qualidade em escala. Metodologias e ferramentas não são suficientes porque elas sempre podem ser mal utilizadas. Por isso, uma cultura de responsabilidade pessoal é algo crítico.

Consequentemente, a maior parte dos arquivos de código fonte é modificada por apenas alguns engenheiros. Apesar de pelo menos mais um engenheiro rever todas as mudanças antes que sejam feitos os commits, um terço dos arquivos de código fonte foram editados por apenas um engenheiro e outro quarto por dois. Apenas 10% dos arquivos foram manipulados por mais de 7 engenheiros. Por outro lado, a distribuição dos engenheiros pelos arquivos possui uma longa cadeia, com os arquivos mais compartilhados sendo utilizados por não menos de 870 engenheiros distintos. Esses arquivos amplamente compartilhados são predominantemente arquivos de bibliotecas e também incluem principais configurações e arquivos de alto nível do PHP.

Testes? Não precisamos de testes…

O Facebook não possui um time de testes independente, porque eles dizem que não precisam de um.

Primeiro, eles dependem muito de revisão de código para encontrar os bugs:

No Facebook, revisão de código ocupa uma posição central. Cada linha de código é escrita e revisada por um engenheiro diferente do autor original. Isso serve a múltiplos objetivos: o engenheiro original é motivado a assegurar que seu código é de alta qualidade, o revisor chega com uma “cuca fresca” e talvez encontre defeitos ou sugira alternativas e, em geral, o conhecimento sobre as práticas de programação e do próprio código se espalham pela empresa.

Desenvolvedores também são responsáveis por escrever testes unitários e seus próprios testes de regressão – eles possuem “dezenas de milhares de testes de regressão” (o que não parece ser suficiente para as mais de 10 milhões de linhas de código em sua maioria em PHP compilado para C++, ambas linguagens nas quais é comum comentar erros) e testes automatizados de desempenho.

E os desenvolvedores também testam o software ao usar a versão de desenvolvimento do Facebook em suas próprias contas pessoais da rede social. De acordo com os autores “este é apenas um aspecto do abandono das técnicas tradicionais de desenvolvimento de software”. Mas desenvolvedores do Facebook usando seus próprios softwares internamente (e considerando isso como “teste”) não é diferente do passado da Microsoft, em que os empregados supostamente deveriam “provar do próprio veneno”, uma prática que surtiu pouco, ou nenhum efeito, na qualidade dos produtos da empresa.

O Facebook também depende dos clientes para testar seu software para eles. O software é lançado em etapas para testes A/B e “experiência em tempo real”, em subgrupos da base de usuários, caso os clientes queiram participar desses testes ou não. Pelo fato de a base de usuários deles ser tão grande, eles podem ter um feedback significativo a partir dos testes, mesmo com uma pequena porcentagem dos seus usuários, o que pelo menos minimiza o risco de inconvenientes para os clientes.

Segurança???

Apesar de o desempenho ser considerado importante para os desenvolvedores do Facebook, não há menção a verificações ou testes de segurança em lugar algum da descrição de como os devops da empresa colocam software para rodar. Sem análise/scanner estático ou dinâmico, teste de invasão ou explicação de como o time de segurança e desenvolvedores trabalham juntos, nem mesmo para “código relacionado à privacidade” – apesar de esse código ser “mantido em padrões mais elevados”, eles não explicam o que são “padrões mais elevados”. Presumivelmente, eles contam com o uso de bibliotecas e frameworks para lidar pelo menos com alguns aspectos de segurança no aplicativo e possivelmente procurar por bugs de segurança em suas revisões de código, mas eles não dizem nada.

Não há muita informação disponível sobre o programa de segurança do Facebook. O time de segurança da empresa parece gastar bastante tempo educando as pessoas sobre como usar o Facebook de forma segura, como desenvolver aplicativos seguros e executando seu programa de caça aos bugs, que paga uma recompensa em dinheiro a pessoas de fora da companhia que foram capazes de encontrar um bug para eles.

Uma busca sobre segurança no Facebook em sua maior parte retorna uma longa lista de falhas públicas de segurança, violações de privacidade e vulnerabilidades de segurança encontradas em todos esses anos e que continuam até hoje. Talvez a falta de um programa efetivo de segurança (appsec) seja a causa para isso.

Essa é a forma como o Facebook desenvolve. Devo me importar?

Apesar de ser interessante ver como funciona por dentro uma empresa tão conhecida como o Facebook e como eles desenvolvem software em grande escala, não fica claro por que esse artigo foi escrito. Há pouco sobre o que o Facebook está fazendo (em seu desenvolvimento frontend, pelo menos), algo que seja exclusivo ou inovador, exceto talvez pela forma como eles usam BitTorrent para enviar código para os milhares de servidores, como faz o Twitter, algo que eu já tinha ouvido há alguns anos na Velocity e que já havia sido escrito antes.

Eu gosto da ideia de desenvolvedores serem responsáveis por seu trabalho, desde o início até a produção, que é um princípio que também seguimos. Revisões de código são boas. Recursos de dark launching são uma boa prática e têm sido comum há um bom tempo (mesmo antes de serem chamadas de “dark lauching”). Não ter testes para appsec não é bom. De qualquer forma, não sei o que podemos aprender ou gostaríamos de usar a partir da experiência deles.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/09/this-is-how-facebook-develops-and.html