Estamos em 2016 e eu ainda me impressiono com a quantidade de desenvolvedores e até mesmo empresas que não controlam a versão do seu código fonte, seja por questões culturais, “falta de tempo”, custo ou falta de informação.
Até uns 15 ou 20 anos atrás, custo até poderia ser considerado um argumento válido, principalmente em se tratando de desenvolvimento para Windows, já que a maioria das soluções conhecidas eram ferramentas pagas e a maioria das empresas de pequeno porte sequer teria orçamento para esse tipo de despesa. É claro que já existiam soluções grátis e até mesmo de código aberto, mas até recentemente pouquíssimas empresas ou mesmo indivíduos confiavam em soluções livres para desenvolvimento profissional “sério”.
Eu mesmo, no começo da minha carreira (em meados de 2000), trabalhei em um projeto cuja versão confiável do código era aquela que estava sendo executada no servidor do site (ASP) e nos meus projetos pessoais e da faculdade o controle de versão que eu fazia consistia em arquivos zip do diretório do código fonte, nomeados como aplicacao_1.zip, aplicacao_2.zip, aplicacao_3.zip, etc.
Desde então, já trabalhei com diversos sistemas de controle de versão: SourceSafe, Clear Case, CVS, SVN, TFS, Mercurial e Git. De fato, no início a tarefa de configurar e usar alguns desses sistemas de controle de versão não era trivial, mas hoje não há mais desculpas. Há agora controles de versão para todos os gostos e eu pretendo mostrar aqui algumas opções que todo desenvolvedor deveria conhecer. As opções que vou mostrar podem ser usadas com custo inicial ZERO e esse é o principal motivo desse post.
Eu acredito em código aberto e na minha opinião, todo desenvolvedor sério deve se envolver de alguma forma com open source, nem que seja apenas acompanhando um projeto sem nunca contribuir com código. Só o fato de acompanhar será um incentivo para os mantenedores do projeto e até mesmo solicitações de funcionalidade ou relatos de bugs são uma forma de contribuição muito importante.
Para os propósitos deste artigo vamos dividir projetos em 2 perfis distintos:
- Código Aberto - projeto cujo código fonte está disponível de forma pública para qualquer pessoa que tenha interesse. Pode ou não aceitar contribuições de terceiros e sempre deverá ser respeitada a licença de uso escolhida pelo criador.
- Código Fechado – projeto pessoal ou corporativo cujo código fonte está disponível apenas para uma pessoa ou grupo de pessoas. Pode ser que o produto final do projeto seja de livre uso, mas o acesso ao código fonte é restrito e claramente limitado.
Para ambos os tipos de projeto acima, minha recomendação de controle de versão é o Git, mas com soluções diferentes de hospedagem. No próximo post vou entrar em mais detalhes sobre minha escolha do Git.
Uma coisa importante de dizer aqui é que Git e GitHub são 2 coisas distintas! Git é um sistema de controle de versão open source criado em 2005 por Linus Torvalds (pai do Linux) e GitHub é uma plataforma e comunidade de desenvolvimento de código aberto que hospeda repositórios Git.
Agora vamos às minhas recomendações:
- Código Aberto – Git com repositório central hospedado no GitHub.
- GitHub oferece repositórios ilimitados para projetos open source com custo ZERO, ou seja, você pode criar quantos projetos quiser no GitHub sem custo algum, mas esses projetos serão públicos e qualquer pessoa terá acesso ao código fonte.
- Sistema de Issue Tracking para relatos de bugs e solicitações de novas funcionalidades. Qualquer usuário do GitHub pode relatar um problema ou sugerir novas funcionalidades nos projetos públicos.
- Apesar de o repositório ser público, seu criador tem total controle sobre quem tem permissão para realizar commits.
- Qualquer usuário do GitHub tem permissão para criar um patch e submeter para o criador do projeto por meio de um Pull Request, mas o criador se reserva o direito de aceitar ou não o Pull Request ou até mesmo adicionar outros usuários como contribuintes do projeto.
- Código Fechado – Git com repositório central hospedado no Visual Studio Team Services (também conhecido como VSO, VSTS ou visualstudio.com).
- VSTS é o oposto do GitHub pois oferece projetos e repositórios privados ilimitados com custo ZERO para projetos com até 5 desenvolvedores.
- Ótimo sistema de Issue Tracking (chamados Work Items no VSTS) para relatos de bugs, solicitações de funcionalidades, controle de progresso e roadmap.
- Permite adicionar stakeholders ilimitados. Stakeholders são usuários que têm acesso ao projeto no VSTS, mas apenas para com objetivo de criar e acompanhar Work Items (Issues). Stakeholders não têm acesso ao código fonte.
- Sistema de Build e Release robusto e extremamente fácil de usar com 240 minutos/mês sem custo. O sistema de Build pode inclusive ser usado com projetos hospedados fora do VSTS, como por exemplo no GitHub (mais detalhes em um próximo post).
- Constante evolução. O time responsável pelo Visual Studio, TFS e VSTS na Microsoft adotou o modelo de desenvolvimento de software Agile, com sprint de 3 semanas, ou seja, o VSTS é atualizado em média 1 vez/mês com correções, melhorias e novas funcionalidades. Vale acompanhar o blog de Brian Harry, Vice Presidente da divisão de Cloud e um dos responsáveis atualmente pelo VSTS.
- Não há opção para criação de repositórios públicos.
Ambas as sugestões acima também oferecem opções pagas. O GitHub permite a criação de repositórios privados por um custo mensal e o VSTS permite adicionar mais desenvolvedores e/ou funcionalidades aos repositórios pagando individualmente ou por meio de assinatura MSDN, mas meu foco aqui era falar das possibilidades sem custo.
Algumas pessoas/empresas temem usar um controle de versão online, por diversos motivos. Os tempos hoje são outros e ambas as minhas sugestões acima são empresas extremamente sérias, sólidas, idôneas e responsáveis. Ambas têm termos bastante extensos sobre privacidade e segurança. Eu poderia até ter falado da opção de usar um servidor TFS local no lugar do VSTS, mas meu objetivo aqui era mostrar opções grátis (TFS local requer uma licença que tem um alto custo) e que MUITOS desconhecem, além é claro da complexidade da manutenção e atualização do servidor local que passaria a ser nossa responsabilidade. O serviço VSTS é tão robusto e seguro que a própria Microsoft o utiliza agora para muitos dos seus próprios produtos como o Visual Studio e o TFS e VSTS, no lugar de servidores internos. Isso para mim é prova mais do que suficiente de que é seguro e robusto o suficiente para times e projetos de qualquer tamanho e importância, pois se não fosse assim a Microsoft não arriscaria colocar seus códigos fontes online dessa forma.
Este é apenas meu primeiro post de uma série sobre o estado do controle de versão em 2016. Nela pretendo mostrar como tirar proveito dos diversos recursos e serviços que temos à nossa disposição hoje para desenvolver software com alto nível de controle e qualidade, da forma mais simples possível e de preferência sem custo algum. No próximo post vou entrar em mais detalhes sobre minha escolha do Git como controle de versão e mostrar como utiliza-lo de forma simples e eficiente com ambas as soluções citadas.