Scegli dove Taiga attende una decisione

Separa quattro decisioni

Il servizio fittizio di attrezzature ha quattro decisioni diverse: accettare il piano, eseguire la build, fare il merge della modifica e distribuirla. Non trattare un solo interruttore come autorizzazione per tutte e quattro.

Prima di cambiare l’autonomia, esamina cosa fa la pipeline del repository dopo il merge. Se il merge sul branch di lavoro avvia un deployment, un merge automatico può avviare anche quel flusso esistente.

Decidi se il piano deve attendere

L’impostazione di prodotto Build on its own by default controlla se un piano completato procede alla build o attende approvazione. Disattivala quando i piani richiedono prima una decisione umana.

L’impostazione Build on its own dell’iniziativa può cambiare il comportamento per la singola iniziativa. Esamina sia il valore predefinito sia le scelte specifiche prima di accodare lavoro.

Approve avvia la build con l’identità della persona che approva, soggetta ai suoi permessi attuali. Un piano fallito non avvia alcuna build. L’automazione della build non autorizza da sola il merge della pull request risultante.

Comprendi la gerarchia del merge

Il merge autonomo ha un controllo separato ed è disattivato finché non viene abilitato. L’integrazione documentata funziona con GitHub, incluso GitHub Enterprise.

Un limite disabilitato nell’organizzazione o nella factory non può essere superato ai livelli inferiori. Un valore predefinito disattivato nel prodotto è diverso: un’iniziativa può abilitare il proprio merge se i limiti superiori lo consentono.

Per il servizio di attrezzature, mantieni esplicito l’ambito iniziale. Un’iniziativa con conseguenze limitate può avere una scelta diversa da una modifica ai controlli di accesso dei dipendenti, entro i confini consentiti.

Rendi obbligatorie le revisioni richieste tramite controlli

Taiga chiede al fornitore del sistema di controllo del codice sorgente se sia consentito eseguire il merge della pull request. La protezione del branch determina verifiche, revisioni e altre condizioni richieste. Il merge autonomo non aggira queste regole.

Se una revisione automatica deve bloccare il merge, rendine il risultato uno status check obbligatorio tramite la configurazione prevista dal repository. Un risultato consultivo non diventa obbligatorio solo perché te lo aspetti.

Controlla anche le approvazioni umane richieste. Una verifica verde non sostituisce un’approvazione imposta dalla policy. Conferma le regole sul branch di destinazione effettivo.

Interpreta un merge fermato

Leggi il motivo nell’iniziativa. Una verifica in attesa, un’approvazione mancante, un conflitto e un piano incompleto richiedono risposte diverse. Taiga ferma il merge autonomo anche quando le correzioni cambiano i criteri che hanno fatto passare verifiche prima fallite. Esamina direttamente quella modifica.

Non rimuovere una verifica obbligatoria solo perché blocca il progresso. Se la verifica non restituisce mai un risultato, correggine la configurazione o usa il processo autorizzato della policy. Esamina il commit attuale dopo ogni correzione.

Mantieni separata l’autorizzazione al deployment

La GitHub App di Taiga esegue il merge autonomo e viene registrata come soggetto che lo ha effettuato. La pipeline del repository mantiene il comportamento di deployment esistente.

In questo scenario, il merge distribuisce in staging. La produzione richiede ancora la decisione e le prove di produzione dell’organizzazione. Conferma che la pipeline imponga questa separazione. Prosegui con la revisione della consegna.