Planos

Um plano é um conjunto ordenado de tarefas agrupadas em fases. Você o aprova antes que o código seja escrito.

Use um quando o trabalho exigir várias alterações em uma ordem específica ou quando quiser ver toda a abordagem antes de se comprometer com alguma delas.

O ciclo de vida#

O planejamento é uma etapa própria, não uma transformação instantânea.

1. O planejamento começa. Assim que a solicitação passar pela Qualificação, o arquiteto explorará o código-fonte e elaborará fases e tarefas. O planejamento começa por conta própria, a menos que a solicitação tenha anexos ou tenha usado o fluxo de trabalho SDLC; nesse caso, começa ao criar o plano ou finalizar a preparação.
2. Você analisa o rascunho. Este é o ponto de intervenção mais barato em todo o sistema.
3. Aprovar, revisar ou reiniciar. Aprovar libera o plano para execução; revisar o envia de volta com seu feedback; reiniciar recomeça o planejamento.
4. Execução. As tarefas são executadas em ordem, respeitando os limites das fases.

Você pode aprovar e executar em uma única etapa ou aprovar e iniciar posteriormente.

Revisar em vez de reiniciar#

Quando um plano está quase correto, revisá-lo mantém o que o arquiteto aprendeu sobre seu código-fonte e aplica seu feedback. Reiniciar descarta isso e começa tudo de novo.

Reinicie quando toda a abordagem estiver errada. Revisar quando a abordagem estiver certa, mas os detalhes não. A revisão é muito mais barata, e o conteúdo de um plano rejeitado não se perde — ele serve de entrada para a próxima tentativa.

Controlando um plano em execução#

Um plano em andamento pode ser pausado, retomado ou cancelado, e você pode acompanhar o progresso em suas fases. Os planos também podem ser clonados, o que é a maneira prática de repetir uma estrutura que funcionou — como uma migração aplicada a um segundo serviço, por exemplo.

Os planos concluídos podem ser arquivados para manter a visualização ativa significativa.

Um único pull request, não um por tarefa#

As tarefas de um plano não abrem um pull request cada uma. Elas trabalham em ramificações próprias e são mescladas em uma ramificação de faixa; essa ramificação é promovida como um único pull request contra sua ramificação base quando o trabalho atende aos requisitos.

Portanto, você analisa o recurso montado uma única vez, com toda a alteração visível, em vez de aprovar fases incompletas uma a uma.

Os planos entre projetos são a exceção: uma tarefa pertencente a um projeto diferente da faixa é promovida separadamente, então você obtém um pull request por repositório. Um pull request não pode abranger dois repositórios.

Quando a ramificação base é atualizada#

Um plano pode rodar por horas, e sua equipe continua fazendo merge na ramificação base nesse período. O plano foi construído, testado e revisado com base na ramificação base existente quando o plano começou. Quando o pull request dele estiver pronto, pode não ser mais a ramificação para a qual será feito o merge.

Quando um plano começa a ser executado, o Coroid registra o último commit da ramificação base como linha de basedo plano. Antes que o pull request do plano possa fazer merge, o Coroid verifica novamente a ramificação base. Qualquer alteração no conteúdo dos arquivos conta, incluindo arquivos que o plano nunca tocou. Um novo esquema de autenticação ou regra de segurança pode tornar o código correto em incorreto sem causar conflito de merge; por isso, o Coroid não espera por um.

Se a ramificação base foi atualizada, Aprovar e mesclar permanece desabilitado e a revisão de promoção lista os novos commits e os arquivos que eles alteraram. Você escolhe o que acontecerá:

• Aceitar nova main (nomeada conforme sua ramificação base) — as alterações não afetam este trabalho. O Coroid registra quem aceitou qual commit e por quê, e esse commit se torna a nova linha de base. Se a ramificação for atualizada novamente enquanto você estiver lendo, o Coroid recusará e mostrará primeiro os commits mais recentes. Nada é aceito sem ser exibido.
• Mesclar e reverificar — o Coroid mescla a ramificação base na ramificação de faixa, resolvendo conflitos se houver algum. Em seguida, faz o processo passar pelo desenvolvedor, QA e revisor novamente, verificando-o conforme os critérios de aceitação do plano e os commits upstream. A aprovação permanece retida até que isso termine. Somente então o novo commit se torna a linha de base. Se o merge ou a reverificação falharem, a decisão volta para você.

A pausa é o padrão. Um projeto pode optar por mesclar e reverificar em vez disso, para que o Coroid inicie sem esperar por você; veja Configurações de repositório e ramificação. A revalidação consome horas de agente.

Um plano reiniciado desde o início registra uma nova linha de base, portanto é executado em relação ao branch base naquele momento. As evidências da tentativa anterior permanecem no histórico, mas não tornam a nova tentativa atual.

Mesclagem forçada também ignora essa verificação e registra o motivo informado para isso. Veja Mesclando.

Fases e paralelismo#

As fases definem ordem, não concorrência. As tarefas dentro de uma fase podem ser executadas em paralelo se a capacidade permitir; a fase seguinte aguarda a conclusão da atual.

Um plano com dez tarefas compatíveis com paralelismo e uma única vaga de agente ainda as executará uma de cada vez. A estrutura não cria capacidade — veja Capacidade e vagas de agente.

Plano ou tarefa?#

No formulário de Novo trabalho, escolha Plano ou Tarefa em Criar como, ou deixe-o em Automático e deixe a Qualificação decidir. Trabalhos que abrangem mais de um projeto sempre viram um plano. Se você escolher um caminho e a Qualificação recomendar o outro, verá a recomendação antes de qualquer coisa ser criada.

O critério é a capacidade de revisão: um pull request que um colega possa ler em uma sessão é uma tarefa; qualquer coisa que precise de várias alterações ordenadas é um plano.

Adotar erroneamente uma tarefa para um trabalho realmente grande é o erro mais arriscado — a tarefa pode ficar sem espaço no meio do caminho, desperdiçando a execução. Escolher um plano incorretamente custa apenas uma etapa de aprovação que não era estritamente necessária.

Portas de entrega#

Um plano pode ter uma porta de entrega que define o que deve ser verdade antes que seu resultado prossiga. Veja Portas de qualidade.

Relacionados#

• Tarefas, planos, sprints e faixas
• Sprints
• Especificações
• Procedência