O que é um fluxo de trabalho baseado na versão?
Aqui, abordamos a forma como pode criar um fluxo de trabalho baseado na nuvem com o GitHub.
O que é um fluxo de trabalho baseado na versão?
Um fluxo de trabalho baseado em versão é um conjunto de padrões e políticas que se concentra no lançamento de software. Embora essa noção possa parecer um objetivo óbvio para uma equipe de desenvolvimento, o valor dessa perspetiva é mais matizado. Nesta unidade, discutimos como ele conduz três partes diferentes do ciclo de lançamento: gerenciar o projeto, selecionar uma estratégia de ramificação e liberar para os clientes.
Planear trabalho com quadros de projeto do GitHub
De uma perspetiva de planeamento, trabalhar em torno do lançamento significa que os problemas estão divididos em iterações distintas que produzem uma nova versão. Essas iterações são frequentemente chamadas de sprints e são encaixotadas em períodos aproximadamente iguais para produzir mudanças incrementais. Outras equipas preferem empacotar versões de lançamento inteiras numa única iteração que pode durar meses ou mais. No GitHub, estas iterações são geridas como projetos.
A caraterística dominante de um projeto é o seu quadro. O quadro é o plano central de registo para a iteração e contém todos os cartões a ser resolvidos. Um cartão pode representar um problema, um pedido Pull ou apenas uma nota genérica.
Por predefinição, cada cartão começa na coluna To do (A fazer), muda para In progress (Em progresso) após o trabalho começar e termina em Done (Concluído). Você pode personalizar essas colunas, adicionar mais colunas ou aplicar automação ao movimento desses cartões e suas propriedades para se adequar ao processo da sua equipe.
Saiba mais sobre a gestão de quadros de projeto.
O estado do projeto do cartão é integrado no repositório. Por exemplo, arrastar um cartão de Fazer para Em andamento altera seu status e atualiza o indicador visual ao lado do título do projeto. A secção verde indica a porção de cartões marcados como Done (Concluído) e a secção roxa é utilizada para cartões In progress (Em progresso). O espaço restante representa a quantidade de cartões que ainda têm de ser iniciados. Além de arrastar cartões ao redor do quadro, você pode atualizá-los a partir de sua visualização principal.
Quando você usa um quadro de projeto, todas as partes interessadas têm uma maneira fácil de entender o status e a velocidade de um projeto. Também pode criar quadros confinados a utilizadores individuais ou uma coleção de repositórios pertencentes a uma organização.
Saiba mais sobre como monitorizar o progresso do seu trabalho com quadros de projeto.
Monitorizar marcos específicos
Para as equipas ou subconjuntos de equipas, o GitHub oferece a monitorização de marcos.
Os marcos são semelhantes ao acompanhamento de projetos, na medida em que há uma ênfase na conclusão priorizada de problemas e solicitações pull. No entanto, quando um projeto pode estar focado no processo da equipe, um marco é focado no produto.
Saiba mais sobre como monitorizar o progresso do seu trabalho com marcos.
Selecionar uma estratégia de ramificação
Os repositórios com múltiplos programadores a trabalhar em paralelo precisam de uma estratégia de ramificação bem definida. Estabelecer uma abordagem unificada no início do projeto evita confusão e frustração à medida que a equipe e a base de código escalam.
O fluxo do GitHub
Além de fornecer uma plataforma para o desenvolvimento colaborativo de software, o GitHub também oferece um fluxo de trabalho prescrito concebido para otimizar a utilização das suas diversas funcionalidades. Embora o GitHub possa trabalhar com praticamente qualquer processo de desenvolvimento de software, recomendamos que você considere o fluxo do GitHub se sua equipe ainda não estiver estabelecida em um processo.
Trabalhar com ramificações de longa duração
Uma ramificação de longa duração é uma ramificação do Git que nunca é eliminada. Algumas equipes preferem evitá-los completamente em favor de recursos de curta duração e ramificações de correção de bugs. Para essas equipas, o objetivo de qualquer esforço é produzir um pedido Pull que intercale o respetivo trabalho no main. Essa abordagem pode ser eficaz para projetos que nunca precisam olhar para trás, como aplicativos Web primários que não suportam uma versão anterior.
No entanto, existem determinados cenários em que uma ramificação de longa duração pode ser a mais útil para uma equipa. O caso mais comum de uma ramificação de longa duração é quando um produto tem múltiplas versões que têm de ser suportadas por um período de tempo prolongado. Quando uma equipa precisa de planear esta consolidação, o repositório deve seguir uma convenção padrão, como release-v1.0, release-v2.0, entre outras. Essas ramificações também devem ser marcadas como protegidas no GitHub para que o acesso de gravação seja controlado e não possam ser excluídas acidentalmente.
As equipas devem manter main como a ramificação de raiz e unir as respetivas alterações às ramificações das versões a montante, desde que se adequem ao futuro do projeto. Quando for a altura, release-v3.0 deve basear-se em main para que o trabalho de manutenção de release-v2.0 não complique o repositório.
Manutenção de ramificações de longa duração
Imagine que a correção de um erro foi intercalada na ramificação release-v2.0 e, em seguida, intercalada novamente a montante em main. Mais tarde, descobriu-se que esse bug também existia na release-v1.0 ramificação e a correção precisava ser backported para os clientes que ainda usavam essa versão. Qual é a melhor maneira de fazer backport dessa correção?
Mesclar o main ramo em release-v1.0 não seria uma opção viável, uma vez que conteria um número significativo de commits que não deveriam fazer parte dessa versão. Pela mesma razão, rebasear-se release-v1.0 no compromisso atual main não seria uma opção.
Uma opção alternativa seria voltar a implementar manualmente a correção na ramificação release-v1.0, mas essa abordagem precisaria de muita reelaboração e não dimensionaria bem em múltiplas versões. No entanto, o Git oferece uma solução automatizada para este problema na forma do seu comando cherry-pick.
QO que é o comando principal do Git?
git cherry-pick é um comando que lhe permite aplicar consolidações específicas de uma ramificação para a outra. Este itera as consolidações selecionadas e aplica-as à ramificação de destino como consolidações novas. Se for necessário, os programadores podem intercalar eventuais conflitos antes de concluir a nova correção.
Saiba mais sobre o comando principal do Git.
Lanças para os consumidores
Quando um produto está pronto para ser lançado, o GitHub simplifica o processo ao empacotá-lo e notificar os consumidores.
Criar uma versão é tão simples como preencher o formulário:
- Introduza uma etiqueta do Git a aplicar, que deve seguir o controlo de versões semântico, como
v1.0.2. O GitHub efetua a gestão do processo de criação da etiqueta do Git que especificar. - Introduza um nome para a versão. Algumas práticas comuns são:
- Usar um nome descritivo
- Use a versão Git
- Use um resumo conciso de como a versão foi alterada desde a anterior
- Use um nome de código ou frase aleatória
- Forneça as notas de versão. Você pode automatizar essa tarefa com o aplicativo Release Drafter, que analisa as alterações desde a versão anterior e inclui os títulos de solicitação pull associados.
- Se você quiser fornecer arquivos como parte da versão, como instaladores pré-construídos, você pode arrastá-los e soltá-los no formulário. Não precisa de empacotar a origem, uma vez que o GitHub faz isso automaticamente.
- Indique se a versão é de pré-lançamento marcando essa caixa. Essa indicação ajuda os clientes a evitar versões de pré-lançamento, se desejarem.
Assim que uma versão é publicada, todos que observam o repositório recebem uma notificação.
Saiba mais sobre as versões do GitHub.