Colaboração e Open Source dentro da empresa

O Github sem sombra de dúvidas mudou a forma como funciona a colaboração em projetos Open Souce. Já existiam alguns websites de colaboração nesse sentido (e até bem conhecidos) como o SourceForge, Google Code, Savannah e vários outros. Todos eles tem várias qualidades mas o Github na minha opinião foi o que conseguiu ser o mais bem sucedido: eles uniram uma interface bem agradável a uma rede social de programadores e o sistema de controle de versão Git.

Colaborar com outros projetos é bem fácil no Github, basta fazer um fork do projeto que eu pretendo colaborar, fazer minhas modificações e depois um “pull request” para o dono do projeto avaliar e integrar (ou não) o meu código ao dele. Antes do Github não funcionava muito diferente disso mas o que ele fez de bom foi facilitar esse fluxo e criar uma rede social bem interessante em torno desse mundo.

Isso é bem diferente de como as empresas normalmente funcionam. No caso da Globo.com, por exemplo, todos os repositórios sempre estiveram amontoados nos servidores CVS e Subversion e consequentemente “escondidos” (pouco visíveis) de possíveis colaboradores. Alguns até tinham permissão de commit restrita para um pequeno grupo e o processo de colaboração era ainda mais difícil. Não dá nem para abrir um branch seu, você tem que fazer as modificações localmente e mandar um patch por e-mail, e o merge geralmente não é muito fácil de fazer quando você tem um grande fluxos de merge para lá e para cá. Imagina então quando você trabalha na versão “v1″ do código e enquanto você produz a “v2″ um outro desenvolvedor pede merge antes de você? Era preciso esperar o merge terminar para dar checkout da versão nova e ficar mais uma vez fazendo o inferno do merge.

No início desse ano resolvemos experimentar usar o Gitorious, que é uma ferramenta similar ao Github porém Open Source e que você pode instalar num servidor da sua empresa. Isso tinha 2 objetivos: (1) criar uma cultura de “enterprise” Open Source e (2) facilitar a colaboração em projetos em que vários times trabalham e commitam ao mesmo tempo.

No início foi um inferno e houve uma rejeição muito grande de muita gente. O modelo de trabalho com o Git é bem diferente do que com CVS e Subversion. Você tem branches (e clones – que é um conceito um pouco diferente) que podem ser locais ou remotos, commits locais que não vão direto para o servidor e pulls/pushes. As pessoas tendem a fazer relações do tipo “o push é o que manda as coisas para o servidor, então ele equivale ao commit”. Mas então o que é o commit do Git? Enfim, não dá pra trabalhar pensando assim, é preciso dar um reset e entender a arquitetura desses sistemas de controle de versão distribuídos para entender que faz sentido sim ter um commit e só depois do push que o código está no repositório (no remoto, porque no local já estava). :)

Também foi difícil aprender a trabalhar com merges. No modelo antigo você evita fazer merges o máximo possível porque o trabalho para fazer isso é enorme. Geralmente você só faz quando acabou de fazer tudo para ter trabalho uma vez só. Ainda bem que existem ferramentas para ajudar (como as ferramentas das próprias IDEs) senão seria complicado. Se você trabalha da mesma forma com o Git geralmente vai se dar mal, porque não existem (não existiam mas estão começando a melhorar) as mesmas ferramentas de merge visual do CVS ou Subversion, e era um parto para fazer a coisa toda funcionar após fazer um merge de uma semana de fork. Com o Git funciona ao contrário: como o merge é automático (na maioria dos casos ele consegue se virar) então a estratégia é fazer merge toda hora, várias vezes por dia, o máximo que der.

Depois de alguns meses de “fricção” hoje já dá para ver um monte de frutos começando a aparecer. Por exemplo, no último sprint do meu time nós precisavamos usar um cliente Python para acessar a engine de busca da Globo.com. Como esse cliente era novo tinha uma série de problemas pequenos que precisavam ser resolvidos, mas o time que é responsável pelo projeto estava com vários compromissos e demoraria 2 semanas para trabalhar nisso. Então o Bernardo e o Andrews decidiram fazer um clone no Gitorious para contribuir com o projeto do time de busca, e eles não só resolveram os problemas como devolveram o código refatorado e com a cobertura de testes bem melhor. O outro time rapidamente integrou o novo código ao projeto e gostou tanto do trabalho deles que eles viraram commiters e agora podem fazer as modificações que forem necessárias em colaboração com o time de busca. Exatamente como funciona no mundo Open Source.

Além desse exemplo, no projeto que estou trabalhando (que é um framework para sites de publicação de conteúdo) temos vários times trabalhando no mesmo código ao mesmo tempo. Nesse momento tem cerca de 10 clones do projeto no nosso Gitorious e talvez cerca de 10 times trabalhando usando o mesmo código para fazer seus “add-ons”. O Git facilita o trabalho dos times para atualizarem constantemente sua base de código com o que entra de novo no branch master do mainline (o repositório principal do projeto) e o Gitorious torna isso tudo mais visível para todos.

Enfim, as vantages que nós passamos a ter com o Git e Gitorious são várias:

  • Todo mundo pode ver facilmente os projetos que existem e quando novos projetos são criados;
  • Todo mundo pode ver o que todo mundo está fazendo e em que estão trabalhando;
  • Todo mundo pode facilmente criar e gerenciar seus projetos (sem precisar do Sys Admin);
  • É bem facil de navegar nos projetos, ver e pegar código dos outros;
  • Todo mundo pode criar seus clones de repositórios para trabalhar em cima do seu código e do código dos outros;
  • Todo mundo pode colaborar de volta sem precisar de um processo complicado para isso;
  • É mais fácil de fazer merges constantes e gerenciar múltiplas colaboracoes simultâneas;
  • Fora as outras features interessantes que o Git tem e os sistemas de SCM antigos não como o stash, clones, merge automático e por aí vai.

Só para dizer um ponto negativo, a documentação de usuários do Git não é das melhores (mas tem melhorado bastante) e alguns comandos não são tão intuitivos (como deletar um branch remoto), mas nada que você não descubra e que não se acostume com o tempo.

Aconselho fortemente a todo mundo que puder que faça isso. Instale o Gitorious e fomente a colaboração entre os desenvolvedores da sua empresa! Se você estiver com muita grana também pode dar uma olhada no Github Firewall Install, que deve ser bem legal mas também é bem caro.

Tags: , , , , , , , , , , ,

23 Responses to “Colaboração e Open Source dentro da empresa”

  1. Denilson says:

    Se alguém conhecer algo similar para Mercurial, avise! ;)

  2. AC de Souza says:

    Todos os desenvolvedores da gerencia onde trabalho usam Windows.

    Tem a questão do desempenho/interface do Git no Windows ser muito ruim, mesmo do mSysGit. Por conta disto tenho olhado para o Bazaar como uma alternativa.

    Como você resolveu esta questão?

    [],
    AC

  3. Jeveaux says:

    Ótimo post, GC!

    Eu me lembro bem dessa fase da rejeição, inclusive participei de algumas discussões hehe.. Hoje aqui na Giran *tudo* está no Github.

  4. Valeu pela mençao GC!

    Cara,

    Vale lembrar que nós fizemos outra colaboraçao. O Django StaticGenerator. Implementamos a suite de testes toda dele fazendo um fork do Github. Agora vamos contribuir de volta para o Django, o que eh bem legal!

    Abraçao,
    Bernardo Heynemann

  5. Parabéns pelo post Guilherme, mas bateu uma pequena curiosidade, esse framework para sites de publicação de conteúdo que você vem trabalhando, pode revelar em qual linguagem? :D

  6. AC de Souza says:

    @gc

    E tem vagas aí? ;)

    [],
    AC

  7. Muito interessante, mas como o amigo disse a respeito da interface para windows, fico com receio de implantá-lo.

    • @Paulo

      Realmente, como eu falei para o @AC de Souza, não sei dizer sobre o funcionamento no Windows porque tem alguns anos que eu (felizmente) não uso mais ele. Mas se vc mudar para Unix vai resolver vários outros problemas além desse. (marketing_mode:on)

  8. AC de Souza says:

    @Paulo

    Tem o Bazaar. Feito pelo pessoal da Canonical, mesmo do Ubuntu.

    A interface, linha de comando, dele é muito boa, possui plugin(precário se comparado com o Subclipse) para o Eclipse. E, no projeto onde eu trabalho, o desempenho não deixa a desejar ta

    O que mais me empolga nele é a documentação e a facilidade de uso, no sentido de que os comandos lembram o dia-dia no Subversion.

    Mas ele não tem um Github. O Lauchpad, que é um equivalente ao Gitorious, me parece interesante, mas *eu* não me acho muito bem na sua interface.

    [],
    AC

  9. Olá Guilherme,

    Parece que é muito interessante usar o Git, pra quem nunca viu nada sobre ele, o que você recomenda como material para iniciar no uso do Git?

  10. AC de Souza says:

    @Marcelo Carvalheiro

    Micro tutorial de Git, Akita on Rails.

    [],
    AC

  11. Christopher Moura says:

    @Marcelo Carvalheiro

    Tem também o GitReady http://pt-br.gitready.com/

  12. Na Locaweb, com a chegada do Fabio Akita, todos os projetos foram migrados do SVN para o Gitorious.

    Alguns desenvolvedores tiveram um pouco mais de dificuldade na transição. Uma das razões foi tentar achar no Git equivalências do que usavam no SVN. Mas passada a fase de adaptação, tudo ser tornou mais fácil. A colaboração entre as equipes, por conta da disponibilidade do código para toda empresa, aumentou bastante.

    Minha equipe atualmente trabalha em ambientes Windows e Linux, mas até uns dois meses atrás era somente Windows, onde usamos o MSysGit nas máquinas de desenvolvimento e no servidor de integração contínua sem problemas.

    Um detalhe importante quanto ao Git no Windows: usamos o Git Bash, ou seja, tudo via linha de comando como se estivéssemos em um ambiente Unix. Não recomendo ninguém usar o Git GUI que é instalado com o MSysGit.

    Abaixo tem algumas dicas de como usar o Git no Windows:
    http://mauriciodeamorim.com.br/2009/01/06/como-usar-git-no-windows/

  13. Realmente a rejeição foi muito grande, inclusive de minha parte. Felizmente no meu time pessoas como o Pellegrino, o Bruno Carvalho e o Guilherme Cirne viam muitos benefícios no Git, e conseguiram arduamente me mostrá-los. Hoje quando temos que dar manutenção em alguns sistemas legados que utilizam CVS e SVN dá até frio na espinha.

  14. [...] da colaboração e criatividade“. Para não ficar repetindo o que já foi escrito, sugiro ler este post do @gchapiewski sobre como o uso apropriado de ferramentas de controle de versão transformou o [...]

  15. Linkei este post no meu blog, muito bom.

  16. [...] years ago I wrote a post about how Git and Github changed the Open Source world and how companies can benefit from this model (in Portuguese, unfortunately, but you can try to [...]

  17. [...] da colaboração e criatividade“. Para não ficar repetindo o que já foi escrito, sugiro ler este post do @gchapiewski sobre como o uso apropriado de ferramentas de controle de versão transformou o [...]

Leave a Reply