Fretebras web dev flow 2.0

Desde setembro de 2019 em nossas tribos e squads estamos adotando para os novos projetos de software o “GitHub flow”, que é um fluxo de trabalho leve e baseado em branch que suporta equipes e projetos em que as implantações são feitas com regularidade.

Este guia explica como e porquê esse fluxo de apenas seis passos se adere ao nosso modelo de trabalho atual, que não exige necessidade de um plano de releases a fim de manter múltiplas versões de um serviço em ambiente de produção, junto ao crescimento contínuo do nosso time de engenheiros geograficamente distribuídos.


1. Crie uma branch

Quando você estiver trabalhando em um projeto, terá várias idéias diferentes em andamento a qualquer momento, algumas das quais estão prontas para serem usadas e outras não. Os branchs existem para ajudá-lo a gerenciar esse fluxo de trabalho.

Ao criar um branch em seu projeto, você cria um ambiente em que pode experimentar novas idéias. As alterações feitas em um branch não afetam a ramificação master; Portanto, você pode experimentar e commitar alterações seguro de que seu branch não será mesclado até que esteja pronto para ser revisado por alguém com quem você está colaborando.

Criando um branch:

ProTip

Branching é um conceito central no Git e todo esse fluxo é baseado nele.
Há apenas uma regra: qualquer coisa na ramificação master é sempre implantável, portanto não deve conter código quebrado, testes falhando e muito menos credenciais de acesso.

Por isso, é extremamente importante que sua ideia seja desenvolvida fora do master ao trabalhar em um recurso ou uma correção. O nome do seu branch deve ser descritivo, separando palavras por “-“, (por exemplo: refactor/r1h1-refatora-autenticacao, feat/r1h2-cria-avatares-resolucao-retina), pra que outros possam ver e compreender o que está sendo trabalhado.

Propomos algumas definições de nomenclatura que auxiliam a relacionar o que o branch objetiva resolver, por exemplo:

  • feat (implementação de nova funcionalidade)
  • fix (correção de um problema existente)
  • refactor (refectory de código que já funcionava)
  • chore (melhoria de código e/ou arquitetura)
  • test (novo cenário de testes)
  • docs (mudança na documentação)
Exemplos:

Ao seguir as definições elencadas, podemos preparar o ambiente de CI/CD para reagir baseado na categoria do branch, ignorando ou adicionando jobs e tornando o processo de deploy mais eficiente.

2. Adicione commits

Depois que seu branch foi criado, é hora de começar a fazer suas alterações. Sempre que você adiciona, edita ou exclui arquivos num contexto de atomicidade funcional, você deve fazer um commit e adiciona-lo ao seu branch. Esse processo de adição de commits acompanha o seu progresso enquanto você trabalha em uma feature-branch.

Os commits também criam um histórico transparente do seu trabalho para que outras pessoas possam seguir e entender o que, e, porque você as fez. Cada commit tem uma mensagem de confirmação associada, que é uma descrição que explica porque uma alteração específica foi feita. Além disso, cada commit é considerado uma unidade de mudança separada. Isso permite reverter as alterações se um erro for encontrado ou se você decidir seguir um caminho diferente.

Dicas gerais:

  • Faça commits com seu email da empresa.
  • Mantenha o .gitignore consistente com as mudanças no seu ambiente.
  • Não permita credenciais de acesso vazarem no código fonte.
  • Não versione arquivos gerenciados como dependência.
  • Não versione arquivos de configuração.
  • Não versione arquivos gerados automaticamente.

ProTip

As mensagens de commit são importantes, principalmente porque o Git rastreia suas alterações e as exibe como confirmadas quando são enviadas ao servidor.

Ao escrever mensagens claras de commit, você agiliza o processo de revisão, facilita a escrita de boas notas de versão (release notes) e ajuda futuros mantenedores do software (e até você mesmo) a descobrir porque determinada modificação foi realizada ou funcionalidade adicionada.

Você sempre pode descrever melhor as mensagens de commit da solução implementada. 🤩

Exemplo:

  • Limite o assunto a 50 caracteres e não adicione ponto final (forneça uma visão geral e rápida)
  • Separe o assunto do corpo da mensagem por um linha em branco
  • Limite as linhas do corpo a 72 caracteres e explique “o que” e “o porque” no lugar do “como” (inclua mais explicações)
  • Use o humor imperativo para descrever a mensagem
Lembre-se, nem todos os commits necessitam de um assunto e um corpo de texto. As vezes uma única linha já é suficiente, especialmente quando a mudança é tão simples que nenhuma contextualização é necessária.

3. Abra uma Merge Request

Uma Merge Request (MR) possibilita iniciar discussões e colaborações sobre seus commits. Como as MR estão totalmente integrados ao repositório Git subjacente, qualquer membro do time pode acompanhar exatamente quais alterações serão mescladas se aceitarem sua solicitação.

Você pode abrir uma MR a qualquer momento durante o processo de desenvolvimento:

  • Quando você tem pouco ou nenhum código, mas deseja compartilhar algumas capturas de tela ou idéias gerais.
  • Quando está bloqueado criativamente e precisa de ajuda ou aconselhamento.
  • Quando está pronto para que alguém revise seu trabalho.

Usando o sistema @menção na sua MR, você pode solicitar feedback de pessoas ou algum time específico, estejam eles no final do corredor ou até mesmo em outro fuso horário.

Dicas para abrir uma MR:

Atualize seu branch master local

No seu feature-branch, efetue o rebase com o head do master

Caso algum conflito aconteça, resolva-o e inclua as alterações, após resolver todos, continue o rebase.

Só então faça o push e abra a MR.

O rebase em sua forma padrão de uso permite que suas alteração sejam realocadas adiante no histórico, recebendo todas as alterações isoladas no seu branch e alinhando-as como se acontecessem após as revisões atualizadas do master, tudo isso sem as complicações de um reverse merge, alem de deixar o histórico mais limpo e linear.

ProTip

MR são úteis para contribuir e para gerenciar alterações em repositórios, pois fornece uma maneira de notificar os mantenedores sobre as alterações que você deseja que eles considerem antes de serem mescladas no branch principal.

(Opcional) Não está feliz com o histórico gerado por sua revisão?

  • Considere realizar um squash para comprimir os vários commits em um só e manter o histórico mais limpo e reversível.

Entretanto cuidado, pois modificação no histórico gera novos hashes identificadores e pode exigir um reenvio forçado dos seus commits, por isso deve ser usado apenas em branchs no qual você é o proprietário.


Ao trabalhar no master ou em qualquer branch compartilhado, evite realizar o --force. Se realmente precisar fazer isso, use a opção --force-with-lease, que evitará substituir o trabalho de outras pessoas, tornando o push não destrutivo.

4. Discuta e revise seu código

Depois que uma MR é aberta, a pessoa ou equipe que está revisando suas alterações pode ter algumas perguntas ou dúvidas. Talvez o estilo de codificação não corresponda às diretrizes do projeto, esteja faltando algo nos testes unitário ou talvez tudo esteja ótimo e tudo esteja em ordem.

As MR foram projetadas para incentivar e formalizar esse tipo de conversa.

Se alguém comentar que você esqueceu de fazer algo ou se houver um erro no código, você poderá corrigi-lo em seu branch e simplesmente realizar o commit e o push das suas alterações. O repositório mostrará seus novos commits e qualquer feedback adicional que você receber na tela de visualização de MR.

Quando fizer sentido, chame os diversos times que trabalharam em conjunto (PMs, POs, PDs, QAs) para colaborar e não centralize sempre aos Devs

ProTip

Os comentários do MR são escritos em Markdown, então você pode incorporar imagens, emojis, usar blocos de texto pré-formatados e outras formatações leves.


5. Deploy

Você pode realizar a implantação (deploy) a partir de um branch para teste final de Garantia da qualidade antes de mesclar no master.

Depois que seu MR for analisado e o branch passar nos testes automatizados, você poderá implantar suas alterações no ambiente de revisão e/ou staging. Se seu branch causar problemas, você poderá recuperá-lo usando o master ainda existente no ambiente produtivo.


6. Merge

Agora que suas alterações foram verificadas nos ambientes de QA/staging, é hora de mesclar seu código no branch principal.

Depois de mesclados, as MR preservam um registro das alterações históricas no seu código. Por serem pesquisáveis, permitem que qualquer pessoa volte na linha do tempo para entender porque e como uma decisão foi tomada.

Ao mesclar manualmente seu branch no master, use a opção --no-ff para gerar um merge commit. Dessa maneira, você facilita o rastreamento, visualização e também a reversão dos recursos incrementados. *2


Não esqueça que você também pode utilizar o botão de Merge disponibilizado por nossa ferramenta de gerenciamento de mudanças.

Agora basta excluir o branch local e remoto.

ProTip

Ao incorporar determinadas palavras-chave no texto da sua MR, você pode associar tasks/issues/features na solicitação. Quando sua MR é mesclada, os itens relacionados também podem ser fechados. Por exemplo, ao digitar a frase Closes #123 você encerraria o issue/task de número 123 no repositório.


Dicas extras de configuração

*1) Sempre que durante seu trabalho precisar mesclar atualização upstream em seu feature-branch, faça-o com --rebase, a menos que haja mais pessoas trabalhando no mesmo branch (nesse caso, discuta quando será o melhor momento), ou se já houver um MR em aberto.

*2) Para garantir que você não se esqueça de adicionar --rebase ao fazer o pull e --no-ff durante o merge, é recomendado pré-definir essas configurações globalmente:

*3) Nunca realize o --rebase em commits que já existem em qualquer lugar, exceto no seu repositório local. Nesse caso opte pelo uso do merge.

Written by 

Fretebras | Software Engineer 🤘

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

doze + dezessete =