Como implementar um fluxo de trabalho de ramificação de tarefas

O processo começa com uma tarefa em seu rastreador de problemas ou sistema de gerenciamento de projetos: Jira, Bugzilla, Mantis, OnTime ou sua própria solução interna. A chave aqui é que tudo o que você faz deve ter uma tarefa associada. Não importa se faz parte de um novo recurso ou de uma correção de bug - crie uma tarefa para isso.

Em seguida, você cria uma ramificação para essa tarefa.

Recomendamos uma convenção de nomenclatura de ramificação simples: Um prefixo ("tarefa" no exemplo) seguido pelo número da tarefa no rastreador de problemas. Isso ajuda você a manter a rastreabilidade total das alterações.

Trabalhe na ramificação da tarefa e faça quantos check-ins forem necessários. Explique cada etapa nos comentários para esclarecer qualquer revisor.

Quando a tarefa for concluída, defina um atributo de "status" no ramo como "resolvido".

Como alternativa, você pode marcá-lo como concluído em seu rastreador de problemas. Tudo depende do seu conjunto de ferramentas específico e de como você realmente acabará implementando o fluxo de trabalho.

Depois de marcar sua tarefa como concluída, ela pode ser revisada por um colega.

Agora é a vez de o revisor examinar suas alterações e verificar se consegue identificar bugs, erros ou inconsistências no seu estilo de codificação, ou quaisquer aspectos do design que devam ser alterados. Se for o caso, a tarefa será reaberta e o ciclo será reiniciado.

A validação é uma etapa opcional.

Algumas equipes "validam" a tarefa - outro membro da equipe faz um pequeno teste exploratório para garantir que o novo recurso ou mudança faça sentido. Eles não procuram bugs (os testes automatizados cuidam disso), mas analisam a mudança do ponto de vista do cliente. O status pode ser definido como "validado" no atributo.

Configure seu sistema de integração contínua (CI) para monitorar todas as ramificações que tenham um determinado conjunto de atributos. Uma ramificação só será considerada pelo sistema de CI quando atingir um determinado status (neste caso, "validado").

Depois que a tarefa é revisada/validada, o ramo da tarefa é testado automaticamente antes de ser mesclado ao principal.

Se o conjunto de testes for aprovado na mesclagem, ele será confirmado e enviado ao sistema de CI para ser criado e testado. Esse processo ajuda a evitar a quebra da construção. Se falhar, o processo será reiniciado e você terá que fazer o rebase a partir do main para resolver quaisquer conflitos.

Se os testes forem aprovados, a mesclagem será registrada e a ramificação estará pronta para ser entregue. Observe que o status agora está definido como "mesclado".

Se a nova versão estiver pronta para ser implementada, o novo conjunto de alterações no main será rotulado como tal e o software será implementado na produção.

Você pode obter uma nova versão após cada nova tarefa passar por esse ciclo, ou pode decidir agrupar algumas. Ao praticar a implantação contínua, implantar cada tarefa na produção é o fluxo de trabalho mais lógico.

Com o Unity Version Control, a etapa de teste e mesclagem automatizados pode ser configurada usando o plug-in da ferramenta de CI escolhida, como Jenkins, Bamboo ou Unity Cloud Build.

Essa etapa também pode ser orquestrada usando o recurso mergebot do Unity Version Control. O mergebot pode mesclar as ramificações e acionar uma compilação para garantir que funcione. As mesclagens são confirmadas somente se a compilação for boa, evitando compilações quebradas.

Gostamos de seguir a seguinte convenção de nomenclatura: prefixo + número da tarefa. Por exemplo, as ramificações podem ser denominadas task1213, task1209 e task1221. O prefixo é "task" (tarefa) e o número representa o número real da tarefa no rastreador de problemas associado.

A captura de tela também mostra uma descrição de cada ramificação juntamente com o número, já que o explorador de ramificações recupera o número do rastreador de problemas. Você também pode ver a descrição do ramo selecionando "display branch task info".

As regras do Scrum determinam que as tarefas não devem durar mais de 16 horas. Essa prática mantém os cronogramas do projeto sob controle.

As ramificações de tarefas devem ser fechadas rapidamente. O ideal é que você tenha muitas tarefas pequenas que possam ser concluídas em apenas algumas horas. Essa estrutura ajuda a manter o ritmo do projeto e facilita a implementação contínua. Uma tarefa maior que se estenda por uma semana, por exemplo, interrompe o ciclo.

Um sinal de alerta a ser lembrado: Não crie tarefas "cortadas a facão". Se você precisar cortar uma tarefa em partes menores, certifique-se de que a tarefa ainda faça sentido isoladamente e possa ser implementada de forma independente.

Os fluxos de trabalho de ramificação de tarefas só podem ser bem-sucedidos com a adesão de toda a equipe.

Como qualquer processo de DevOps, há um componente cultural nesse fluxo de trabalho. As ramificações de tarefas têm como objetivo comunicar abertamente o progresso e evitar silos. Antes de impor um fluxo de trabalho ou uma forma específica de trabalhar com as tarefas, você precisa buscar o alinhamento. Ajude os membros da equipe a entender os benefícios de fechar uma pequena parte de uma tarefa maior hoje, em vez de lutar com tarefas maiores por mais tempo.

Pergunte a si mesmo (ou aos seus colegas de equipe): Você realmente precisa do código que acabou de concluir na tarefa1213 para iniciar a tarefa1209?

As tarefas tendem a ser muito mais independentes do que você imagina. Sim, eles podem ser sobre o mesmo tópico, mas você não precisa tocar exatamente no mesmo código. Você pode simplesmente adicionar algo novo e confiar que a mesclagem fará seu trabalho.

Suponha que 1213 e 1209 no exemplo acima fossem correções de bugs em vez de tarefas. Você não quer que um dependa do outro. Você quer que eles atinjam o principal e sejam liberados o mais rápido possível. Mesmo que eles toquem o mesmo código, são correções diferentes.

Cada check-in deve ajudar o revisor a seguir sua linha de raciocínio e processo para entender como você lidou com a tarefa.

Deixar os detalhes nos comentários de seu check-in ajudará o avaliador, pois ele não precisará descobrir toda a filial. Em vez disso, eles farão o diff changeset por changeset. E eles seguirão a explicação pré-gravada que você fez para esclarecer cada etapa da tarefa. Eles não se encontrarão olhando para uma lista em negrito de mais de 100 arquivos modificados. Em vez disso, eles seguirão passo a passo.

Cada ramo de tarefa deve estar pronto para ser integrado depois de concluído. Se uma alteração for frágil ou fizer com que o produto se comporte de forma estranha, a tarefa não deve ser definida como concluída.

Esse é um pequeno preço a ser pago pelos benefícios da automação. A equipe deve estar alinhada com a definição de "pronto", ou seja, "pronto para produção". Em troca, você pode ter a tranquilidade de saber que passar sua tarefa para a produção é fácil, totalmente automatizado e não resultará em um incêndio às 2h da manhã.

O que são alternâncias de recursos? Eles são essenciais para a implantação contínua. Essa técnica de desenvolvimento de software permite que os recursos sejam testados antes de serem concluídos e estarem prontos para o lançamento.

Uma alternância de recurso pode ocultar, ativar ou desativar o recurso durante o tempo de execução. Ele permite que você ative um recurso apenas para a equipe de desenvolvimento, para um pequeno número de usuários iniciais ou para todos. Por exemplo, um desenvolvedor pode habilitar um recurso para testes e desabilitá-lo para outros usuários durante o desenvolvimento.

Vamos dar uma olhada em um exemplo. Você tem um grande recurso dividido em sete partes que serão convertidas em tarefas e implementadas usando ramificações de tarefas. Como é possível implementar a Parte 4 se nada mais está pronto?

A Parte 4 pode ser mesclada à ramificação principal e até mesmo implantada enquanto ainda estiver oculta, usando uma alternância de recursos.

O fato de estar oculto não significa que o novo código não passa por testes antes do lançamento. Quando o recurso completo estiver pronto para ser ativado, as partes individuais já terão sido testadas várias vezes. A integração da última parte não acionará uma fusão de grande porte; é apenas uma parte menor passando para a principal.