Usando o Git Workflow para trabalhar com times remotos

Crescimento do crescimento de pull requests de uma organização e pull requests realizados por usuário
Crescimento do uso de pull requests de uma organização e pull requests realizados por usuário

Que o controle de versão ajuda bastante nosso dia a dia de desenvolvimento, não há dúvida. Trabalhar com a idéia de usar o FTP para gerenciar o código de plataformas inteiras, e até mesmo para websites simples não faz mais sentido e não deve ser usado se você quer que o seu projeto siga adiante.

O controle de versão não só veio para tornar mais fácil e escalável o gerenciamento dos repositórios. Ele está de certa forma integrado ao processo de desenvolvimento ágil para controle de releases, versões e colaborações entre os seus membros e não membros.

Usado adequadamente, ele pode ser expandido para formas colaborativas para receber contribuições em qualquer parte do mundo.

Eventos patrocinados pelo Github em 2016 pelo mundo (fonte: Octoverse)

Atualmente o controle de versão permite que você envie diferentes versões do seu projeto juntamente com uma completa infraestrutura, de forma que todo ambiente pode ser escalado e facilmente controlado em diferentes ambientes.

O Github está aí para comprovar o que estou dizendo. Hospedar seu repositório de código com ele abre as portas para um mundo de desenvolvedores que assim como você trabalha com diversas tarefas de desenvolvimento. Isto é válido para todas as empresas que compartilham de alguma forma a tecnologia Open Source e vê nela as vantagens que o mundo colaborativo proporciona. Até empresas como a Microsoft perceberam que proteger seu código é se fechar para melhorias, contribuição e adoção por uma comunidade. O Github se tornou algo usado amplamente por empresas e no ambiente corporativo.

O Git se tornou uma ferramenta de trabalho para times remotos e projetos de abrangência mundial. E o Github tornou-se a plataforma de referência para colaboração de código, automatizando e simplificando várias tarefas do Git.

A colaboração do código em qualquer projeto, seja ele com modelo Open Source ou privado, aumenta as possibilidades de feedback e melhor adoção dentre uma comunidade de desenvolvedores.

Infográfico com números do Github em dezembro de 2016. Fonte: https://octoverse.github.com/
  • 5.8 Milhões de usuários
  • 331 Mil organizações ativas
  • 19.4 Milhões de repositórios ativos
  • 10.7 Milhões de issues ativas

Pull request, uma das ferramentas mais poderosas do Git

Em um projeto que usa o controle de versão Git é possível fazer um Pull Request. Com ele é possível requisitar uma integração do código que você modificou no projeto original para que ele possa ser integrado. Com ele você requisita que o código seja integrado no repositório principal.

Os criadores do projeto que o modificou originalmente pode realizar revisões do código que você deseja entregar. Não só existem as revisões, como existe um processo de trabalho automatizado baseado nestas avaliações de código. Estas avaliações podem ser feitas pelos membros do projeto, que criam ferramentas de teste automatizadas para avaliar seu código em diferentes situações.

Modelos de desenvolvimento colaborativo

Com os modelos de desenvolvimento colaborativo adotado em diversas empresas por todo o mundo, é possível ter diferentes controles de acesso e modos de contribuição, e não é a toa que o Github é basicamente uma comunidade de troca de código.

Os modelos de Fork e Branch permitem uma flexibilidade e modos de contribuição para o seu projeto.

No Fork você faz uma versão sua do projeto original, criando uma versão para você mesmo. O Fork é ideal para quem não é membro do projeto

Modelo de Fork de um projeto usado no Git (fonte: Atlassian — https://www.atlassian.com/git/tutorials/comparing-workflows#forking-workflow)

Na branch você cria uma ramificação no projeto inicial, criando um novo ciclo de vida para o projeto. A branch pode ser criada no repositório original e passar pelo processo de Pull Request para ter o código integrado.

Modelo de Branch de um projeto usado no Git (fonte: Atlassian — https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow)

Todos eles se integram no código final por estas maneiras que podem ser complementares. Membros do projeto podem criar branches e requisitarem integrações através de um Pull Request e pessoas externas podem fazer um fork do projeto e requisitar que o código seja integrado.

Revisões automáticas

Usando Pull Request, diversas verificações que são realizadas no código podem ser verificadas, como por exemplo:

  • Verificação estática do estilo do código
     Com isto, podemos verificar se o código segue os padrões de implementação requeridos para aquele projeto ex: O Airbnb tem uma forma específica de aceitar o código Javascript
  • Executar testes automatizados
     O projeto pode rodar automaticamente testes funcionais, unitários e até mesmo de interface para verificar que o código não irá quebrar as funcionalidades existentes

Neste processo, podemos pedir quem requisitou uma integração de código que faça modificações e que se adeque ao padrão de contribuição, o contributing guideline, onde está descrito as tecnologias e padrões usados no projeto.

Para iniciar um processo de Pull Request, você primeiro precisa ser capaz de reproduzir o projeto em seu ambiente para desenvolver novas funcionalidades, corrigir bugs ou realizar testes. Por isto uma boa documentação do projeto é essencial para que você entenda de forma rápida como ele funciona e como realizar os testes localmente.

Um projeto colaborativo bem definido possui geralmente um guia de instalação prático para que os demais desenvolvedores do projeto possam ter todo o ambiente de desenvolvimento necessário para seguir com o projeto.

Basicamente, um processo de Pull Request envolve:

  1. Obter o código do repositório em um estado (Pode ser uma versão fechada, o repositório principal ou até mesmo alguma branch de outra pessoa que desenvolveu uma versão diferente)
  2. Você pode criar uma branch (se tiver as permissões necessárias) ou criar um Fork do projeto (é realmente como se você “cortasse” o projeto para uma versão própria).
  3. Você então realiza as mudanças
  4. Enviar o pedido do Pull Request e aguardar as verificações automáticas
  5. Dependendo dos requisitos do projeto, o código pode ser automaticamente integrado com alguém com as permissões de administrador realizar as autorizações necessárias

Os Pull Request atendem diversos tipos de tarefas em um projeto:

  • Corrigir Bugs
  • Traduções
  • Novas funcionalidades
  • Documentação

Ele pode ser usado por times de diversos tamanhos, em diferentes contextos. Empresas e projetos Open Source podem ser guiados totalmente por Pull Request de funcionários e colaboradores.

Várias ferramentas de integração podem ser utilizadas no Github para tornar esta tarefa mais fácil, assim temos integrações com o Heroku, Travis, assim como Gitter, que permite que você entre em chats do projeto

The Github universe technologies

Um exemplo prático

Na empresa onde trabalho, o Processo de Pull Request é usado em todos os projetos. Cada equipe tem sua política de contribuição. A equipe que trabalho, por exemplo, você precisa de um ícone 👍 para seguir adiante com um release e cada projeto tem seu requisito de quantas aprovações são necessárias para ele seguir em frente.

Basicamente o processo do Git workflow consiste em:

  1. Fazer um fork ou uma branch do projeto e realizar as modificações desejadas
  2. Solicitar uma integração do código
  3. Passar por revisões, tanto automáticas quanto dos membros do projeto
  4. Ter seu código aprovado e integrado

Um processo de Pull Request aprovado, com possibilidade de reverter o código, caso algo dê errado, além de visualizar as mudanças num ambiente totalmente novo para testar as modificações realizadas.

Para ilustrar um processo de aprovação de um Pull Request, irei mostrar como integrei o código de um projeto para o lançamento de uma nova versão, no site da Truppie.

A Truppie é uma plataforma de reservas de passeios que desenvolvi para ser utilizada por guias de turismo facilitar as vendas de seus passeios. Ele é hospedado no Heroku, usa o Travis para rodar os testes automatizados e a cada revisão, uma nova infraestrutura com todo o projeto é disponibilizada no endereço do pull request, no formato http://pullrequest-id-herokuapp.com.

Exemplo de um desenvolvimento usando uma ferramenta de integração contínua onde usa o Heroku, o Travis-CI juntamente com o Github

http://blog.alexandremagno.net/wp-content/uploads/2017/04/truppie-git-workflow.mov

Para finalizar, um vídeo mostrando na prática o projeto sendo integrado, nele eu executo o seguinte processo:

  1. Executo os testes automatizados localmente (É importante que você desenvolva o projeto com boas práticas de TDD e BDD para isto realmente fazer a diferença)
  2. Envio o código para a branch que foi utilizada para realizar o Pull Request
  3. Após os testes automatizados rodarem remotamente na branch enviada, uma completa infraestrutura de review para as modificações realizadas fica disponível para teste
  4. Com os testes automatizados passando e alguém revisando, o Pull Request é aceito e o código vai para produção

Assim temos uma completa infraestrutura remota de contribuição sem ter dor de cabeça ou medo quando algo é modificado.