Esta é a página à qual o restante da documentação faz referência. Ela nomeia cada etapa de execução para que outros artigos possam ser precisos sobre onde algo acontece.
O caminho
- 1
EspecificaçãoO que será construído e como você saberá que funcionou.
ArquitetoVocê pode editar - 2Planejamento
Passos ordenados, revisados antes de qualquer código ser escrito.
ArquitetoVocê aprova - 3
ConstruçãoCódigo e testes escritos em um ambiente isolado.
Desenvolvedor - 4
VerificaçãoSua suíte de testes, além de verificações e portas de qualidade.
QA - 5
RevisãoUma passagem de revisão automatizada sobre o diff.
Revisor - 6Pull request
Em uma branch no seu repositório, aguardando sua ação.
Você faz a fusão
Falhas de verificação e observações de revisão corrigíveis retornam ao desenvolvedor como retrabalho, antes que qualquer pull request seja aberto.
Essas etapas são as mesmas nos dois modos como uma tarefa pode ser executada. No modo padrão, a plataforma move a tarefa de uma etapa para a próxima. No modo Coordenador, o agente de planejamento atua como coordenador da tarefa, entrega cada etapa ao agente certo e decide o que acontece após cada resultado, incluindo o envio de trabalho de volta. De qualquer forma, uma etapa é encerrada por suas próprias verificações. Veja Funções dos agentes para saber como os dois modos diferem.
Especificação
Coroid não começa com sua frase. Primeiro, ele transforma sua descrição em uma especificação: o que será construído, o que está explicitamente fora do escopo e os critérios de aceitação que determinam se o trabalho foi bem-sucedido.
Isso é importante porque os critérios de aceitação são o que a etapa de verificação testa posteriormente. Uma especificação vaga gera um trabalho difícil de avaliar.
Você pode ler e editar a especificação na aba Especificação da tarefa antes do início da execução.
O guia de desenvolvimento orientado a especificação explica como escrever critérios testáveis, definir limites de escopo e manter a mesma definição de sucesso durante o planejamento, implementação e revisão.
Planejar
Para qualquer coisa além de uma pequena alteração, a especificação se torna um plano: um conjunto ordenado de etapas, agrupadas em fases. Você aprova o plano antes que o código seja escrito.
Rejeitar um plano é barato e é a decisão certa quando a abordagem está errada. Rejeitar depois que o código é escrito é caro. Esta é a etapa em que seu julgamento tem mais influência.
Construir
Um agente clona o repositório em um espaço de trabalho isolado e trabalha nele. Ele lê o código, escreve a alteração e cria ou atualiza os testes.
O espaço de trabalho é descartável e específico para cada tarefa. Nada que um agente faça afeta seu branch padrão, e duas tarefas executadas simultaneamente não podem ver o trabalho em progresso uma da outra.
Verificar
Sua própria suíte de testes é executada primeiro — esse é o sinal mais forte disponível, pois codifica o que sua equipe já considerou importante.
Além disso, portas de qualidade executam o que sua organização configurou: limites de cobertura, linting, testes de navegador em um deploy de pré-visualização e as Segurança proteções. Uma porta bloqueante interrompe a tarefa; uma porta consultiva registra um achado e permite que ela continue.
Revisão
Um agente revisor lê o diff da mesma forma que um colega faria e produz achados. Os achados que podem ser corrigidos são enviados de volta para retrabalho; os demais são anexados ao pull request para que você os veja.
É por isso que um Coroid pull request chega já revisado — não para substituir sua revisão, mas para que sua revisão não seja a primeira.
Pull request
O branch é enviado e um pull request é aberto contra seu branch base, contendo a alteração, os testes, os resultados de verificação e os achados da revisão. Se o código já atende ao que a tarefa pede, não há nada para enviar: a QA verifica o código inalterado e a tarefa termina sem um pull request.
A automação de tarefas do Coroid termina aqui. O merge é sua responsabilidade.
Após o merge
Abra Lançamentos para preparar o commit exato que você pretende lançar. Um release pode conter vários pull requests mesclados, um commit direto ou trabalho mesclado fora do Coroid. A porta de release e as aprovações referem-se a esse commit e a um ambiente específico. Seu pipeline o implanta; o Coroid registra um sucesso observado ou uma atestação explícita antes de mostrá-lo como lançado. Uma tarefa marcada como COMPLETED ou um pull request mesclado por si só não comprovam a implantação.
Status das tarefas
O status de uma tarefa indica onde ela se encontra no caminho acima:
| Status | Significado |
|---|---|
PENDING | Aceito, aguardando um slot de agente disponível |
IN_PROGRESS | Sendo trabalhado ativamente |
PENDING_REVIEW | O trabalho foi feito e revisado, aguardando integração ou aprovação |
COMPLETED | O trabalho da tarefa foi concluído; a implantação é rastreada separadamente |
NEEDS_HUMAN_REVIEW | Coroid não pode prosseguir sozinho e está fazendo uma pergunta a você |
PAUSED | Parado temporariamente, resumível |
FAILED | A execução não pôde ser concluída |
CANCELLED | Parado por você |
WONT_FIX | Fechado deliberadamente sem realizar o trabalho |
O que determina a produtividade
Um slot de agente Executa uma tarefa por vez. As vagas definem o quanto de trabalho pode ocorrer em paralelo; elas não aceleram a conclusão de nenhuma tarefa específica. A duração de uma tarefa depende do tamanho da alteração e do tempo que sua suíte de testes leva para executar.
Próximo
Funções dos agentes — qual agente cuida de cada etapa do trabalho. Depois, veja Lançamentos para o caminho pós-merge pelos seus ambientes.