O Coroid possui quatro unidades de trabalho. Elas se aninham, e escolher a certa depende principalmente do tamanho do trabalho e de quanto dele deve ser executado ao mesmo tempo.
| Unidade | Tamanho | Termina em |
|---|---|---|
| Tarefa | Uma alteração | Um pull request |
| Plano | Um recurso, em fases | Um pull request para todo o plano |
| Sprint | Um bloco de trabalho ao longo do tempo | O que quer que seja produzido pelas tarefas |
| Faixa | Um fluxo de trabalho paralelo | O branch onde o trabalho de um plano é integrado |
Tarefa
A unidade básica. Uma tarefa é uma unidade de trabalho que produz um pull request, e é o que realmente é executado — planos, sprints e faixas são todas formas de organizar tarefas.
Se você consegue descrever o resultado em um parágrafo e um revisor pode ler o resultado de uma só vez, trata-se de uma tarefa.
Plano
Quando o trabalho requer várias alterações em uma ordem específica, ele se torna um plano: um conjunto ordenado de tarefas agrupadas em fases, que você aprova antes que qualquer código seja escrito.
Use um plano quando:
- etapas posteriores dependerem das anteriores
- você quiser ver toda a abordagem antes de se comprometer com ela
- o trabalho for um recurso e não apenas uma alteração
Aprovar o plano é o ponto de intervenção mais econômico no sistema. Rejeitar uma abordagem aqui custa um minuto; rejeitá-la depois que três tarefas já foram executadas custa três execuções.
Como um plano chega ao seu repositório
As tarefas de um plano não abrem um pull request cada uma. Elas trabalham em seus próprios branches e são mescladas em uma faixa de branch, e esse branch é promovido como um único pull request contra o seu branch base.
task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘Assim, você revisa o recurso montado de uma vez, com toda a alteração à sua frente, em vez de aprovar fases incompletas individualmente.
A exceção ocorre quando o trabalho abrange vários projetos: uma tarefa pertencente a um projeto diferente daquele onde a faixa é promovida será tratada separadamente, então planos entre projetos geram um pull request por repositório. Isso é inevitável — um pull request não pode abranger dois repositórios.
Sprint
Um contêiner com prazo definido para o trabalho, com suas próprias métricas e linha do tempo. Sprints respondem a "o que estamos fazendo neste período e como foi" em vez de "como este recurso é construído".
Use um sprint quando estiver coordenando o trabalho de uma equipe ao longo de um período. Use um plano quando estiver decompondo um recurso. Eles não são alternativas — um sprint pode conter tarefas que pertencem a vários planos.
Faixa
Uma faixa é onde o trabalho paralelo de um plano é integrado. As tarefas direcionam-se ao branch da faixa em vez do seu branch base, permitindo que vários agentes progridam simultaneamente sem colidir, e o resultado montado é promovido como um único pull request assim que atender aos requisitos.
Enquanto um plano diz respeito à ordem, uma faixa diz respeito à concorrência e integração. Se você tem capacidade para vários agentes e um trabalho que não precisa ser estritamente sequencial, a faixa permite que eles rodem juntos e ainda cheguem como uma única alteração passível de revisão.
Escolhendo
A questão não é quantos pull requests você deseja — tanto uma tarefa quanto um plano chegam como um só. Trata-se de quanto trabalho precisa acontecer antes que o resultado valha a pena ser revisado.
- Esta é uma alteração que um revisor poderia ler de uma só vez? Sim → tarefa.
- Precisa de várias alterações ordenadas antes de fazer sentido como um todo? Sim → plano. Sua faixa cuida de executar as partes em paralelo onde for possível.
Sprints complementam tudo isso como uma camada de planejamento e relatórios.
O que limita quanto pode ser executado ao mesmo tempo
Não a estrutura — a capacidade. Um plano com dez tarefas seguras para paralelismo e apenas uma vaga de agente as executará uma de cada vez. Veja Capacidade e vagas de agente.