Esta é a página de referência para o restante da documentação. Ela nomeia cada etapa de execução para que outros artigos possam ser precisos sobre onde algo ocorre.
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.
Esses estágios são os mesmos em ambos os modos de execução de uma tarefa. No modo padrão, a plataforma move a tarefa de um estágio para o próximo. No modo Coordenador, o agente de planejamento permanece na tarefa como coordenador, entrega cada estágio ao agente certo e decide o que acontece após cada resultado, incluindo o retorno do trabalho. De qualquer forma, um estágio é encerrado por suas próprias verificações. Veja Funções dos agentes para entender 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 o estágio de verificação utiliza para testar posteriormente. Uma especificação vaga gera um trabalho difícil de avaliar.
Você pode ler e editar a especificação na aba Especificação 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 alterações maiores que pequenas, 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 após o código ser escrito é caro. Este é o estágio em que seu julgamento tem maior influência.
Construir
Um agente clona o repositório em um espaço de trabalho isolado e trabalha ali. 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 por tarefa. Nada que um agente faça afeta seu branch padrão, e duas tarefas executadas simultaneamente não conseguem visualizar o trabalho em progresso uma da outra.
Verificar
Sua própria suíte de testes é executada primeiro — esse é o sinal mais confiável 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, varredura de segurança, testes de navegador em um deploy de pré-visualização. 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. 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 em relação ao seu branch base, contendo a alteração, os testes, os resultados de verificação e as observações de revisão. Se o código já atender aos requisitos da tarefa, não há necessidade de enviar nada: a equipe de QA verifica o código sem alterações, e a tarefa é concluída sem a criação de 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
er. Um lançamento pode conter vários pull requests mesclados, um commit direto ou
trabalho mesclado fora do Coroid. A porta de lançamento 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 marcá-lo como lançado. Uma tarefa
marcada 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 | Em execução ativamente |
PENDING_REVIEW | Trabalho concluído e revisado, aguardando integração ou aprovação |
COMPLETED | Trabalho da tarefa 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 | Interrompido por você |
WONT_FIX | Fechado deliberadamente sem realizar o trabalho |
O que determina o throughput?
Uma vaga de agente executa uma tarefa por vez. As vagas definem quanto trabalho ocorre em paralelo; elas não fazem com que uma tarefa específica seja concluída mais rápido. A duração de uma tarefa depende do tamanho da alteração e do tempo que sua suíte de testes leva para rodar.
Próximo
Funções dos agentes — qual agente gerencia cada etapa do trabalho. Depois, veja Lançamentos para conhecer o caminho pós-merge pelos seus ambientes.