O que é um fluxo de trabalho baseado em versão?
Aqui, abordamos como você pode criar um fluxo de trabalho baseado em versão usando o GitHub.
O que é um fluxo de trabalho baseado em versão?
Um fluxo de trabalho baseado em versão é um conjunto de padrões e políticas que se concentram no lançamento de software. Embora essa possa parecer uma meta óbvia para uma equipe de desenvolvimento, o valor dessa perspectiva é mais sutil. Nesta unidade, abordaremos como ela impulsiona três partes diferentes do ciclo de versão: gerenciar o projeto, selecionar uma estratégia de ramificação e liberar para os clientes.
Planejar o trabalho com painéis de projeto do GitHub
Do ponto de vista do planejamento, concentrar-se na versão significa que os problemas são divididos em iterações distintas que produzem uma nova versão. Essas iterações costumam ser chamadas de sprints e são divididas em períodos aproximadamente iguais para produzir alterações incrementais. Outras equipes preferem empacotar versões de lançamento inteiras em uma só iteração que pode durar alguns meses ou mais. No GitHub, essas iterações são gerenciadas como projetos.
O recurso dominante de um projeto é seu painel. O painel é o plano central de registro da iteração e contém todos os cartões que precisam ser resolvidos. Um cartão pode representar um problema, uma solicitação de pull ou, até mesmo, apenas uma observação genérica.
Por padrão, cada cartão começa na coluna Tarefas pendentes, passa para Em andamento após o trabalho começar e termina em Concluído. Você pode personalizar essas colunas, adicionar mais colunas ou aplicar a automação à movimentação desses cartões e de suas propriedades para que se encaixem no processo de sua equipe.
Saiba mais sobre o gerenciamento de painéis de projeto.
O status do projeto do cartão é integrado em todo o repositório. Por exemplo, arrastar um cartão da coluna Tarefas pendentes para Em andamento altera seu status e atualiza o indicador visual ao lado do título do projeto. A seção verde indica os cartões marcados como Concluídos, enquanto a roxa é dedicada aos cartões Em andamento. O espaço restante representa a quantidade de cartões que ainda serão iniciados. Além de arrastar os cartões pelo painel, você pode atualizá-los na exibição principal.
Com o uso do painel de projeto, todos os stakeholders têm uma forma fácil de entender o status e a velocidade de um projeto. Você também pode criar painéis voltados a usuários individuais ou a uma coleção de repositórios pertencentes a uma organização.
Saiba mais sobre como acompanhar o progresso do trabalho com painéis de projeto.
Acompanhar marcos específicos
Para equipes ou subconjuntos de equipes, o GitHub oferece o acompanhamento de marcos.
Os marcos são semelhantes ao acompanhamento de projetos, pois há ênfase na prioridade de conclusão dos problemas e das solicitações de pull. No entanto, enquanto o projeto pode ter como foco o processo da equipe, o marco tem como foco o produto.
Saiba mais sobre como acompanhar o progresso do trabalho com marcos.
Selecionando uma estratégia de ramificação
Repositórios que têm vários desenvolvedores trabalhando em paralelo precisam de uma estratégia de ramificação bem definida. A seleção de uma abordagem unificada no início do projeto evita confusão e frustração conforme a equipe e a base de código aumentam.
O fluxo do GitHub
Além de fornecer uma plataforma para o desenvolvimento de software colaborativo, o GitHub também oferece um fluxo de trabalho prescrito projetado para otimizar o uso de diversos recursos. Embora o GitHub funcione com praticamente qualquer processo de desenvolvimento de software, recomendamos considerar o fluxo do GitHub caso sua equipe ainda não tenha selecionado um processo.
Trabalhando com branches de longa vida
Um branch de longa vida é um GIT branch que nunca é excluído. Algumas equipes preferem evitá-las completamente em favor de ramificações de recursos e de correções de bug de curta duração. Para essas equipes, a meta de qualquer esforço é produzir uma solicitação de pull que mescla seu trabalho de volta em main. Essa abordagem pode ser eficaz em projetos nos quais nunca é necessário olhar para trás, como aplicativos Web internos que não dão suporte a uma versão anterior.
No entanto, há alguns cenários em que um branch de longa vida atende melhor aos interesses da equipe. O caso mais comum de uso dos branches de longa vida é quando um produto tem várias versões que precisam ter suporte por um período longo. Quando uma equipe precisa se planejar para ter esse compromisso, o repositório deve seguir uma convenção padrão, como release-v1.0, release-v2.0 e assim por diante. Esses branches também precisam ser marcados como protegidos no GitHub para que o acesso de gravação seja controlado e eles não possam ser excluídos acidentalmente.
As equipes ainda devem manter main como o branch raiz e mesclar as alterações do branch de versão upstream, desde que elas se encaixem no futuro do projeto. Quando chegar a hora, release-v3.0 deverá ser baseado em main, para que o trabalho de manutenção de release-v2.0 não complique o repositório.
Manutenção de branches de longa vida
Suponha que uma correção de bug tenha sido mesclada no branch release-v2.0 e, depois, tenha sido mesclada upstream mais uma vez em main. Depois, descobriu-se que esse bug também existia no branch release-v1.0 e a correção precisava de backport para os clientes que ainda estavam usando essa versão. Qual é a melhor maneira de fazer backport dessa correção?
Mesclar o branch main em release-v1.0 não seria uma opção viável, pois haveria um número significativo de confirmações que não deveriam fazer parte dessa versão. Pelo mesmo motivo, trocar a base de release-v1.0 na confirmação atual de main não seria uma opção.
Uma opção alternativa seria reimplementar manualmente a correção no branch release-v1.0, mas essa abordagem exigiria muito retrabalho e não seria bem dimensionada em várias versões. No entanto, o Git oferece uma solução automatizada para esse problema na forma de seu comando cherry-pick.
O que é o comando cherry-pick do Git?
git cherry-pick é um comando que permite aplicar confirmações específicas de um branch em outro. Ele simplesmente itera as confirmações selecionadas e as aplica ao branch de destino como novas confirmações. Se necessário, os desenvolvedores podem mesclar conflitos antes de concluir o backport.
Saiba mais sobre cherry-pick no Git.
Lançamento para os consumidores
Quando a versão de um produto está pronta para ser lançada, o GitHub simplifica o processo de empacotá-la e notificar os consumidores.
A criação de uma versão é tão simples quanto preencher o formulário:
- Insira a tag Git a ser aplicada, que deve seguir o controle de versão semântico, como
v1.0.2. O GitHub gerencia o processo de criação da tag Git especificada. - Insira um nome para a versão. Algumas práticas comuns são:
- Usar um nome descritivo
- Usar a versão do Git
- Usar um resumo conciso de como essa versão foi alterada com relação à anterior
- Usar uma frase aleatória ou um nome de código
- Fornecer as notas sobre a versão. Você pode automatizar esta tarefa com o aplicativo Release Drafter, que analisa as alterações desde a versão anterior e inclui os títulos das solicitações de pull associadas.
- Se quiser fornecer arquivos como parte da versão, como instaladores pré-criados, arraste-os e solte-os no formulário. Você não precisa empacotar a origem, pois o GitHub cuida disso automaticamente.
- Indique se esta é uma versão de pré-lançamento marcando essa caixa. Esta indicação ajudará os clientes a evitarem versões de pré-lançamento, se desejarem.
Após a publicação de uma versão, todas as pessoas que observam o repositório receberão uma notificação.
Saiba mais sobre as versões do GitHub.