Escolha onde a Taiga espera por uma decisão

Separe quatro decisões

O serviço fictício de equipamento tem quatro decisões diferentes: aceitar o plano, executar a implementação, fazer merge da alteração e fazer o deployment. Não trate um único interruptor como autorização para as quatro.

Antes de alterar a autonomia, examine o que a pipeline do repositório faz depois do merge. Se o merge para a branch de trabalho desencadear um deployment, um merge automatizado também pode desencadear esse fluxo existente.

Decida se o plano deve esperar

A definição de produto Build on its own by default controla se um plano concluído avança para implementação ou espera por aprovação. Desative-a quando os planos precisarem primeiro de uma decisão humana.

A definição Build on its own de uma iniciativa pode alterar esse comportamento para essa iniciativa. Examine a predefinição e qualquer escolha específica antes de colocar trabalho na fila.

Approve inicia a implementação em nome da pessoa que aprova, sujeita às suas permissões atuais. Um plano que falhou não inicia uma implementação. A automação da implementação não autoriza, por si só, o merge do pull request resultante.

Compreenda a hierarquia de merge

O merge autónomo é controlado separadamente e fica desativado até ser ativado. A integração documentada suporta GitHub, incluindo GitHub Enterprise.

Um limite desativado na organização ou na factory não pode ser ultrapassado nos níveis inferiores. Uma predefinição de produto desativada é diferente: uma iniciativa pode ativar o seu próprio merge se os limites superiores o permitirem.

No serviço de equipamento, mantenha o âmbito inicial explícito. Uma iniciativa de consequências reduzidas pode ter uma escolha diferente da de uma alteração aos controlos de acesso dos trabalhadores, dentro dos limites permitidos.

Torne obrigatórias as revisões necessárias

A Taiga pergunta ao fornecedor de controlo de versões se o pull request pode ser integrado por merge. A proteção de branch determina as verificações, revisões e outras condições obrigatórias. O merge autónomo não contorna essas regras.

Se uma revisão automatizada tiver de bloquear o merge, torne o seu resultado uma verificação de estado obrigatória através da configuração suportada pelo repositório. Um resultado meramente consultivo não se torna obrigatório por esperar que o seja.

Verifique também as aprovações humanas obrigatórias. Uma verificação verde não substitui uma aprovação exigida pela política. Confirme as regras na branch de destino real.

Interprete um merge interrompido

Leia a razão na iniciativa. Uma verificação pendente, uma aprovação em falta, um conflito e um plano incompleto exigem respostas diferentes. A Taiga também interrompe o merge autónomo quando as correções alteram os critérios que fizeram passar verificações anteriormente falhadas. Reveja diretamente essa alteração.

Não remova uma verificação obrigatória apenas porque bloqueia o progresso. Se nunca reportar um resultado, corrija a configuração ou use o processo de política autorizado. Examine o commit atual depois de qualquer correção.

Mantenha separada a autorização de deployment

A Taiga GitHub App executa o merge autónomo e fica registada como autora do merge. A pipeline do repositório mantém o comportamento de deployment existente.

Neste cenário, o merge faz deployment para staging. A produção continua a exigir a decisão de produção da organização e as respetivas evidências. Confirme que a pipeline impõe esta separação. Prossiga para a revisão da entrega.