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, essas iterações são gerenciadas como projetos.

A característica dominante de um projeto é o seu conselho. O quadro é o plano central de registro para a iteração e contém todos os cartões que devem ser resolvidos. Um cartão pode representar um problema, um pedido Pull ou apenas uma nota genérica.

Por padrão, cada cartão começa na coluna Tarefas pendentes e passa para Em andamento depois que o trabalho começa antes de terminar em 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 como gerenciar 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 seção verde indica a parte dos cartões marcados como Concluído, enquanto o roxo é usado para cartões em andamento. 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 acompanhar o progresso do seu trabalho com quadros de projeto.

Monitorizar marcos específicos

Para equipas, ou possivelmente subconjuntos das mesmas, o GitHub proporciona acompanhamento 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 acompanhar 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 Git que nunca é excluída. 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 a escolha seletiva 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:

• Insira uma tag Git para aplicar, que deve seguir o versionamento 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.