GitHub e GitLab | A história e importância dos sistemas de controle de versões

O que são?

GitLab e GitHub são sistemas de controle de versões, são ferramentas que fazem que os programadores possam trabalhar em equipe sem querer se matarem. Vamos falar das diferenças, vantagens e desvantagens de cada um.

História

No mundo antigo, as pessoas gerenciavam suas versões como nomes como “Versão Final”, “Versão Final 2.0”, “Versão final final final essa sim”. Curiosamente, hoje em dia ainda há pessoas que infelizmente vivem nesse mundo do passado e não conhecem um mundo melhor. Isso não acontece só no mundo da programação, mas também no mundo do design, produção audiovisual e mais.

Um dos mais famosos do passado é o Concurrent Version System, ou CVS. CVS era muito bom, popular e também muito velho, mas mostrou ao mundo algo lindo que é o sistema de controle de versões de uma maneira distribuída e que realmente funcionava em vários sistemas. Mas era difícil de entender.

Para torná-lo mais fácil, para ter diferentes usuários, que fosse Open Source e mais, nasceu Subversion, ou SVN. Eu usei esse sistema por muito tempo na época de Cristalab e foi meu primeiro contato com um sistema de controle de versões. Uma das features mais interessantes é a culpa ou comando blame para saber que pessoais escreveram tais linhas de código e assim pode dizê-las: “foi você a pessoa que quebrou Cristalab”. Subversion não era suficiente, em especial no mundo Open Source. O projeto mais importante do mundo de código aberto é Linux. Criado por Linus Torvalds.

Assim, ele decidiu criar do zero seu próprio sistema de controle de versões e chamou-o de Git. Git é um sistema distinto aos anteriores porque as pessoas podem fazer uso de ramificações. Você pode ter três ramificações diferentes, com nomes diferentes, onde você pode fazer cambios diferentes de um mesmo arquivo e onde diferentes pessoas podem estar trabalhando em coisas diferentes. Logo, você pode fundir todas essas mudanças e enviá-las a produção em uma só ramificação que pode ser a master.

Assim funciona o Kernel do Linux. Muitas vezes múltiplos Kernel do Linux são mantidos ao mesmo tempo, mas o que acontece quando se encontra o mesmo bug em diferentes kernels? É possível tirar uma ramificação do bug, corrigir o bug e aí fundir o código na versão final. Essa é a magia e isso permite que várias pessoas, inclusive se não trabalham no mesmo lugar ou se não se conhecem, mas se usam os mesmos padrões, podem trabalhar sobre o mesmo arquivo ou mesmo tipo de projeto.

Tem um quadrinho muito bom de XKCD que explica como funciona Git:

E ele tem razão, Git é incrível mas precisa que você tenha conhecimentos de terminal e linha de comandos. E sim, todas as pessoas que programam deveriam conhecer isso, mas pode ser difícil, principalmente se você estiver começando. Existem interfaces gráficas para Windows e Mac para tornar o processo mais amigável, mas ninguém tinha feito algo centralizado até 2012 quando nasceu GitHub.

GitHub

GitHub é uma das mais importantes ferramentas da história da programação. É, em resumo, uma rede social de código. É uma série de projetos conectados com programadores, conectados com companheiros que podem dar uma estrela ou fazer fork no seu projeto.

Foi tão famoso quando lançou, que se deram ao luxo de levantar as rodadas de investimentos. Uma série A de $100M, uma série B de $250M e foram adquiridos pela Microsoft por $7,5 bilhões.

GitLab

Anos depois, nasceu GitLab… Basicamente é Gitub mas open source, e a partir daí começaram a se separar muito mais. A ideia principal é ter algo igual a GitHub, mas em código aberto.

É uma empresa famosa porque passou pela Y Combinator, é YC 2015 assim como a Platzi. Já levantou quatro rodadas de investimento e já alcançou ter $165.5 milhões e é avaliado em $1,1 bilhão.

Contribuição

A maior contribuição do GitHub ao mundo não é só o fato de dar uma interface web ao sistema de controle de versões, mas são os Pull Requests. O que são? É ter um código e outra pessoa pode melhorá-lo adicionando certa quantidade de linhas; quem possui o código tem a opção de aceitar ou não a proposta.

Outras contribuições incríveis do GitHub à humanidade é o perfil de usuário de programador onde, basicamente, voçês podem ver o que cada desenvolvedor ou programador ajudou num projeto.

Essa é a magia que tem o GitHub e por isso, por muito tempo consideraram o GitHub uma empresa impossível de tocar.

Até que nos últimos anos mudaram a teoria em que o software é desenvolvido e nasceu DevOps. A fusão de Development, o processo de Quality Assurance e IT Operations (operações de tecnologia da informação). Como GitHub tem uma API aberta, conseguiu que muitas empresas começassem a usá-lo nesse ciclo de operações e assim nasceu uma grande quantidade de startups e ferramentas.

No processo, vários programadores e equipes de desenvolvimento, a medida que o código se tornava cada vez mais complexo, se deram conta de que precisávamos mudar nossa metodologia de desenvolvimento e começaram a automatizar os processos para que, com apenas um botão, o código fosse enviado a produção; com outro, os testes já programados eram realizados e, se tudo der certo, esperar que outro programador o revise com um Pull Requests e Code Review. Antes, isso tudo era manual.

E isso basicamente cria três grandes teorias no mundo do desenvolvimento:

• Continuous Integration: é um processo onde cada mudança realizada no código deve ser testada e verificada pelos testes escritos anteriormente, realiza-se o deploy do código até a fase de staging.
• Continuous Delivery: é o mesmo processo anterior, mas de forma mais automatizada e, além disso, nossos testes de aceitação (acceptance tests) devem ser de alta qualidade. Porque Continuous Delivery se assegura que cada mudança realizada esteja pronta para ser lançada em produção.
• Continuous Deployment: é o sonho, levar o código a produção sem que tenham humanos no processo.

Agora o processo de DevOps se tornou mais complexo.

Alguém deve ser responsável por todo o Ciclo de DevOps, das ferramentas, de como se integram… Porque existem muitas ferramentas disponíveis e elas adicionam camadas que podem tornar um ataque/invasão possível. Um dos problemas mais comuns ultimamente nos ambientes de desenvolvimento é que os hackers obtêm acesso a um dos processos de Continuous Deployment, Integration ou Delivery e, justo aí, injetam código que podem causar danos à aplicação, criar backdoors, trazer vírus ou ataques parecidos. Alguém também deve monitorar e verificar que todo esse processo seja defensável.

E essa é a parte boa do GitLab, pois perceberam que, como open source, poderiam criar um ambiente onde tudo acontece, onde, em vez de ter que usar quinze ferramentas diferentes, poderiam usar tudo ao mesmo e serem a ferramenta única e definitiva para todo o ciclo de vida de DevOps.

Contudo, Microsoft já tinha criado algo parecido antes de comprar o GitHub, chamado Azure DevOps. Ele faz toda a integração do ciclo através da Microsoft fazendo também Continuous Integration, Delivery Collaboration, código, também é possível integrar com Kubernets (apesar de ser da Google), com Docker e com qualquer coisa mais.

Conclusão

São duas empresas que seguem crescendo muito e cada vez mais estão a par de suas ofertas. Lembre-se de não ser fiel apenas uma empresa, não diga que já que aprendeu GitHub não deveria aprender mais nada, porque você não sabe o que pode acontecer no futuro.

Eu, por muito tempo, fiz isso porque fui estúpido. Resisti em aprender Git e GitHub porque acreditava que Subversion era genial e que GitHub não era tão superior a Subversion para mim… Mas agora é muito melhor. E, por isso, acredito que melhorei como programador na época. Por isso é importante nunca parar de aprender.