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

O processo começa com uma tarefa no 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 total rastreabilidade das mudanças.

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

Quando a tarefa estiver concluída, defina um atributo de “status” na ramificação como “resolvido.”

Alternativamente, você pode marcá-la como concluída no seu rastreador de problemas. Tudo depende do seu conjunto de ferramentas particular e de como você realmente acabará implementando o fluxo de trabalho.

Uma vez que você marque sua tarefa como concluída, ela pode ser revisada por um colega.

Agora é a vez do revisor olhar suas mudanças e ver se consegue identificar bugs, erros ou inconsistências no seu estilo de codificação, ou quaisquer aspectos de design que devem ser alterados. Se sim, a tarefa será reaberta e o ciclo recomeça.

A validação é uma etapa opcional.

Algumas equipes irão "validar" a tarefa - outro membro da equipe fará um teste exploratório curto para garantir que o novo recurso ou mudança faz sentido. Eles não procuram por bugs (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 todos os ramos que têm um determinado atributo definido. Um ramo só será considerado pelo sistema de CI quando atingir um determinado status (neste caso, "validado").

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

Se a suíte de testes passar a mesclagem, ela será confirmada e enviada ao sistema de CI para construir e testar. Esse processo ajuda a evitar quebrar a construção. Se falhar, o processo será reiniciado e você terá que rebasear do principal para resolver quaisquer conflitos.

Se os testes passarem, a mesclagem é registrada e o ramo agora está pronto para ser entregue. Observe que o status agora está definido como "mesclado".

Se a nova versão estiver pronta para ser implantada, o novo conjunto de mudanças no principal é rotulado como tal e o software é implantado em 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 em produção é o fluxo de trabalho mais lógico.

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

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

Gostamos de seguir a seguinte convenção de nomenclatura: prefixo + número da tarefa. Por exemplo, as ramificações podem ser nomeadas task1213, task1209 e task1221. O prefixo é "task", 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 para cada ramificação junto com o número, uma vez que o explorador de ramificações recupera o número do rastreador de problemas. Você também pode ver a descrição da ramificação selecionando "exibir informações da tarefa da ramificação."

As regras do Scrum afirmam 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. Idealmente, você deve ter muitas pequenas tarefas que pode fechar em apenas algumas horas. Essa estrutura ajuda a manter o ritmo do seu projeto e facilita a implantação contínua. Uma tarefa maior que se estende por uma semana, por exemplo, interrompe o ciclo.

Uma bandeira vermelha a ter em mente: Não crie tarefas de "corte de machete". Se você precisar dividir uma tarefa em partes menores, certifique-se de que a tarefa ainda faça sentido isoladamente e possa ser implantada de forma independente.

Os fluxos de trabalho de ramificação de tarefas só podem ter sucesso com o apoio de toda a equipe.

Como qualquer processo de DevOps, há um componente cultural neste fluxo de trabalho. As ramificações de tarefas são sobre comunicar abertamente o progresso e evitar silos. Antes de impor um fluxo de trabalho ou uma maneira particular de trabalhar com tarefas, você precisa buscar 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 a seus colegas de equipe): Você realmente precisa do código que acabou de terminar na tarefa1213 para começar a tarefa1209?

As tarefas tendem a ser muito mais independentes do que você pode pensar. Sim, elas podem estar no 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 uma dependa da outra. Você quer que elas cheguem ao principal e sejam lançadas o mais rápido possível. Mesmo que toquem o mesmo código, são correções diferentes.

Cada check-in deve ajudar o revisor a seguir seu raciocínio e processo para entender como você abordou a tarefa.

Deixar detalhes nos comentários do seu check-in ajudará o revisor, pois ele não precisará comparar toda a ramificação. Em vez disso, eles vão comparar as mudanças, uma a uma. E eles estarão seguindo a explicação pré-gravada que você fez para esclarecer cada etapa da tarefa. Eles não se verão olhando para uma lista ousada de mais de 100 arquivos modificados. Em vez disso, eles irão passo a passo.

Cada ramo de tarefa deve estar pronto para integração assim que finalizado. Se uma mudança for frágil ou fizer o produto se comportar de maneira estranha, então a tarefa não deve ser considerada finalizada.

Este é um pequeno preço a pagar pelos benefícios da automação. A equipe deve alinhar-se na definição de "pronto", significando "pronto para produção". Em troca, você pode desfrutar de tranquilidade sabendo que mover sua tarefa para produção é fácil, totalmente automatizado e não levará a uma correria às 2:00 da manhã.

O que são toggles de recurso? Esses são críticos para a implantação contínua. Essa técnica de desenvolvimento de software permite que recursos sejam testados antes de serem concluídos e prontos para lançamento.

Um toggle de recurso pode ocultar, habilitar ou desabilitar o recurso durante a execução. Ele permite que você habilite um recurso apenas para a equipe de desenvolvimento, um pequeno número de primeiros adotantes ou para todos. Por exemplo, um desenvolvedor pode habilitar um recurso para teste e desabilitá-lo para outros usuários durante o desenvolvimento.

Vamos olhar para um exemplo. Você tem um grande recurso dividido em sete partes que serão convertidas em tarefas e implementadas usando ramos de tarefa. Como é possível implantar a Parte 4 se nada mais estiver pronto?

A Parte 4 pode ser mesclada ao ramo principal e até implantada enquanto ainda está oculta usando um toggle de recurso.

Oculto não significa que o novo código pula os testes antes do lançamento. Quando toda a funcionalidade estiver pronta para ser ativada, as partes individuais já terão sido testadas várias vezes. A integração da última peça não acionará uma mesclagem de grande escala; é apenas uma parte menor passando para o principal.