Coroid modela um ciclo de vida de software completo, não apenas a etapa de compilação. A maior parte dele é executada automaticamente; uma parte é um ponto de verificação opcional que você ativa quando o trabalho é relevante o suficiente para justificar sua utilização.
O fluxo de trabalho SDLC opcional
No Novo trabalho formulário, em configurações avançadas, há uma caixa de seleção:
Usar o fluxo de trabalho SDLC (opcional) — revise a intenção e as especificações antes do planejamento. Deixe essa opção desativada para iniciar o plano diretamente a partir do seu resumo.
Ele está desativado por padrão. Com ele desativado, o planejamento começa a partir do seu resumo assim que for aprovado na Qualificação. Ativado, dois artefatos são produzidos e aprovados primeiro:
- Intenção — o propósito real do trabalho, com as decisões e suposições por trás dele registradas.
- Especificação — escopo, exclusões e critérios de aceitação.
Só após a aprovação desses itens é que o planejamento tem início.
Quando ativá-lo
Ative-o quando o custo de construir algo errado for alto, quando a solicitação vier de alguém que não irá revisar o plano pessoalmente ou quando o resumo contiver uma suposição que você prefere ver escrita e acordada.
Deixe-o desativado quando o resumo já for inequívoco. Uma etapa de aprovação extra em trabalhos rotineiros gera atrito sem benefícios — e a etapa de aprovação do plano ainda se aplica de qualquer forma.
As cinco etapas
O ciclo de vida completo ocorre em cinco fases, cada uma gerando evidências utilizadas pela próxima.
| Etapa | O que acontece | Status |
|---|---|---|
| Definir | Uma solicitação ambígua se transforma em intenção aprovada, decisões, suposições e medidas de sucesso. | Versão beta |
| Visualizar | Conceitos de interface opcionais, refinados e aprovados como orientação de design. | Versão beta |
| Entregar | O plano é decomposto e os agentes o executam. | Disponível |
| Comprovar | Os requisitos são mapeados para tarefas, verificações, resultados de revisão e alterações em pull requests. | Disponível |
| Melhorar | Monitoramento, correção e avaliações transformam regressões em tarefas do próximo ciclo. | Disponível |
- DefinirIntenção aprovada, decisões, pressupostos e medidas de sucessoVersão beta
- VisualizarConceitos de interface opcionais, aprovados como orientação de designVersão beta
- EntregarO plano é decomposto e os agentes o executamDisponível
- ComprovarRequisitos mapeados para tarefas, verificações, observações e alteraçõesDisponível
- MelhorarRegressões tornam-se trabalho para o próximo cicloDisponível
OpcionalAtive o fluxo de trabalho SDLC para aprovar a intenção e a especificação antes do início do planejamento.
Melhorar alimenta o próximo ciclo: monitoramentos, remediações e avaliações transformam regressões em novo trabalho.
Definir e Visualizar estão em desenvolvimento ativo. Entregar, Comprovar e Melhorar são os processos executados em todas as tarefas atualmente, independentemente de o ponto de verificação estar habilitado ou não.
Por que os artefatos são versionados?
As Aprovações vinculam-se a uma versão exata de um artefato. Editar um artefato aprovado cria um rascunho novo, em vez de alterar silenciosamente o que foi acordado.
É isso que torna uma aprovação significativa. Uma aprovação que fica vinculada à 'especificação' em vez de a uma versão específica dela aprova qualquer coisa que o documento venha a dizer posteriormente, o que na verdade não constitui uma aprovação.
Funções de aprovação
As responsabilidades de produto, design, técnica, segurança e lançamento podem ser atribuídas de forma independente, de modo que a pessoa que aprova as implicações de segurança não seja necessariamente a mesma que aprova o escopo.
Linhagem de evidências
O objetivo de gerar evidências em cada etapa é permitir que um pull request finalizado possa ser rastreado até suas origens: essa alteração implementa essa tarefa, que vem desse requisito, que deriva dessa intenção aprovada.
Essa cadeia é o que torna a entrega autônoma auditável. Sem ela, você tem código funcionando, mas sem saber por que ele corresponde ao que foi solicitado.
Do código revisado ao lançamento
pull request é o resultado do ciclo de trabalho. Depois que as regras do seu repositório permitirem o merge, um Lançamento fixa um SHA de commit completo e registra quais alterações esse commit contém. Sua porta de prontidão avalia esse commit exato para um ambiente escolhido. As Aprovações vinculam-se ao snapshot da porta; editar o candidato ou a política torna as decisões anteriores obsoletas.
Solicitar a implantação inicia uma tentativa no seu pipeline conectado. Um retorno de chamada do provedor ou uma atestação manual registra o que chegou a um ambiente, e um canário pós-implantação registra a saúde separadamente. Portanto, a tarefa, pull request e Lançamento têm significados distintos: o trabalho concluído não é evidência de que o código chegou à produção.
Como isso se relaciona com os planos
O fluxo de trabalho do SDLC e planos são pontos de verificação diferentes:
- O fluxo de trabalho do SDLC aprova o que deve ser construído, antes mesmo de existir uma abordagem.
- O plano aprova como ele será construído, antes que o código exista.
Você pode usar um, ambos ou nenhum. Ambos são mais baratos do que revisar um pull request finalizado com o qual você discorda.