7 motivos para termos voltado ao Github
Em abril desse ano nós resolvemos migrar do Github para o Bitbucket. Ficamos fascinados pela integração do Bitbucket com o Jira, ferramenta que utilizamos para gerenciar as tarefas do time de desenvolvimento. Também nos sentimos atraídos pela economia que a mudança iria nos gerar. Pagávamos $7 / usuário / mês no Github, enquanto no Bitbucket conseguiríamos entrar no plano standard, pagando apenas $3 / usuário / mês:
A migração dos repositórios foi tranquila. E realmente era um tremendo facilitador poder acessar nossas tarefas do Jira (e editá-las) diretamente pelo Bitbucket, sem precisar trocar de site.
Porém, como nem tudo são flores, começamos a perceber algumas limitações que nos frustavam. As limitações ficaram mais evidentes com o passar do tempo, já que estávamos nos habituando a utilizar pull requests para todos os processos de code review.
Essas frustrações foram nos incomodando e culminaram na nossa volta para o Github no final de setembro. Revendo agora, foram tempos sombrios esses meses no Bitbucket.
Neste artigo vou te mostrar os 7 principais motivos que nos fizeram decidir pela volta para o Github. Quem sabe eles possam te convencer a não trocar ou até mesmo a voltar, assim como nós fizemos.
Vamos lá!
Os motivos de termos voltado
#1 — PRs com code highlight
Pode até parecer algo trivial, mas code highlight durante um code review de um pull request ajuda demais. Isso porque estamos acostumados com o highlight por conta de nossas IDEs. Nós basicamente esperamos que o código tenha isso.
Além do mais, os highlights nos ajudam até mesmo a identificar problemas de sintaxe. Por isso, pesamos esse fator para voltar para o Github.
Abaixo temos a comparação de um código java, primeiro no Bitbucket e depois no Github:
No Github a experiência é nitidamente melhor.
Inclusive existe um ticket aberto para isso: https://jira.atlassian.com/browse/BCLOUD-8673.
#2 — Marcar arquivos como “visto” durante um review
Um pull request que altera vários arquivos (o que pode acontecer facilmente com a mudança de nome de um pacote, por exemplo) se torna muito mais chato de revisar no Bitbucket do que no Github. Com o Github, é possível marcar cada arquivo já revisado como visto. Isso, inclusive, se mantém caso você saia da página e volte para terminar o review mais tarde. No Bitbucket, o que temos mais perto disso é a possibilidade de colapsar um arquivo já revisado.
Veja as comparações:
Também existe um ticket para esse: https://jira.atlassian.com/browse/BCLOUD-19679.
#3 — Comentários vinculados à blocos de código (várias linhas)
Imagine que você encontre um trecho de código que não faz muito sentido ou que pode ser melhorado. O ideal seria poder selecionar esse trecho de código e comentar informando o autor do PR da sua sugestão de mudança.
No Github é possível selecionar múltiplas linhas no momento de adicionar um comentário durante o review de um PR:
Com o Bitbucket ficamos restritos a comentar apenas uma única linha, o que pode ir contra ao que estamos tentando referenciar.
E olha o ticket aberto aqui de novo: https://jira.atlassian.com/browse/BCLOUD-5547
#4 — Tratar comentários como alterações pendentes
Isso é algo muito bacana do Github que é difícil entender como o Bitbucket ainda não tem.
Sempre que você comentar algo durante um code review, o Github irá iniciar o que ele chama de “Conversation”. Essa conversation fica atrelada as linhas das quais você comentou e pode ser resolvida:
Esse comportamento é extremamente útil. O Github trata cada comentário como se fosse uma alteração pendente no código, o que na maioria esmagadora dos casos vai ser verdade.
No Bitbucket, o comentário fica assim:
O botão “Create task” cria uma “todo list” vinculada ao comentário:
Porém, isso ainda não é a mesma coisa. E pra gente, esse fluxo não fez muito sentido.
#5 — Possibilidade de criar templates para aberturas de PRs
Aqui na Prolog nós trabalhamos com “Definitions of Done” (Definições de Pronto) ou simplesmente DoDs, como gostamos de chamar. Esses DoDs são um checklist que precisa ser concluído para que possamos considerar uma tarefa como finalizada.
Usando o Bitbucket, éramos obrigados a deixar os DoDs como um checklist no Jira, nosso gerenciador de tarefas. Porém, reviews de código não eram feitos no Jira, sendo necessário verificar itens em dois locais para concluir um review: Jira e Bitbucket.
O Github, por outro lado, resolve nosso problema permitindo a criação de um “pull request template”.
Para fazer um, basta criar um arquivo com nome pull_request_template.md na raiz do repositório. Esse arquivo suporta markdown e nele você define qualquer conteúdo que quer que apareça sempre que um PR for aberto. Este é o arquivo de um de nossos repositórios:
Dessa forma, sempre que um pull request for aberto nesse repositório, ele virá com essas informações preenchidas:
E o melhor: é possível marcar os DoDs sem precisar editar a descrição do PR, isso porque o markdown é interativo, sendo possível, inclusive, reordenar os DoDs:
#6 — Solicitar mudanças em um PR
O Github possui um fluxo de pull request que fez muito mais sentido para nós do que o existente no Bitbucket. No fim, seria possível atingir o mesmo resultado com as duas ferramentas, mas o conceito incorreto nos incomodava bastante.
No Bitbucket, só existem dois possíveis estados para mover um PR após um code review: Approved ou Declined:
Já com o Github, existe explicitamente o conceito de requisitar mudanças (Request changes):
Além disso, também é possível simplesmente fechar um PR sem fornecer feedback nenhum. Seria o equivalente ao “Decline” do Bitbucket.
#7 — Redução de preço do Github
Por último, mas não menos importante, houve uma redução nos valores praticados pelo Github. Essa redução ocorreu pouco depois de migrarmos para o Bitbucket (triste). Nós saímos de uma faixa de $7 / usuário / mês para uma de $4 / usuário / mês, apenas $1 mais caro que o Bitbucket.
Com essa alteração, passou até mesmo a ser possível utilizar o Github de forma gratuita para times (com algumas limitações). Veja o anúncio dessas alterações no modelo de cobrança aqui: https://github.blog/2020-04-14-github-is-now-free-for-teams.
Conclusão
No fim, percebemos que nenhuma integração com o Jira era mais valiosa do que esses pontos extras que o Github nos entrega. Migrar os repositórios de um para o outro foi tranquilo, passamos mais trabalho reescrevendo nossas automações no Jira que transitam as tarefas de estado com base no estado de um PR. Porém, ainda com tudo isso, sentimos que valeu muito a pena termos voltado. E agora vai ser difícil sairmos.
