Trieu on espera Taiga una decisió

Separeu quatre decisions

El servei fictici d’equipament té quatre decisions diferents: acceptar el pla, executar la construcció, fusionar el canvi i desplegar-lo. No tracteu un sol interruptor com una autorització per a totes quatre.

Abans de canviar l’autonomia, examineu què fa el pipeline del repositori després de la fusió. Si fusionar a la branca de treball activa un desplegament, una fusió automatitzada també pot activar aquest flux existent.

Decidiu si un pla ha d’esperar

El paràmetre del producte Build on its own by default controla si un pla completat passa a la construcció o espera aprovació. Desactiveu-lo quan els plans necessitin primer una decisió humana.

El paràmetre Build on its own d’una iniciativa pot canviar aquest comportament per a aquella iniciativa concreta. Examineu tant el valor predeterminat com qualsevol opció específica abans de posar feina a la cua.

Approve inicia la construcció amb la identitat de la persona que aprova, subjecta als seus permisos actuals. Un pla que falla no inicia cap construcció. L’automatització de la construcció no autoritza, per si sola, la fusió de la pull request resultant.

Enteneu la jerarquia de fusió

La fusió autònoma es controla per separat i es manté desactivada fins que s’activa. La integració documentada admet GitHub, inclòs GitHub Enterprise.

Un límit d’organització o de fàbrica desactivat no es pot anul·lar des d’un nivell inferior. Un valor predeterminat de producte desactivat és diferent: una iniciativa pot activar la seva pròpia fusió si els límits màxims ho permeten.

Per al servei d’equipament, manteniu explícit l’abast inicial. Una iniciativa de conseqüències limitades pot tenir una opció diferent d’un canvi en els controls d’accés dels empleats, dins dels límits permesos.

Feu que les revisions requerides siguin obligatòries

Taiga pregunta al proveïdor de control de versions si la pull request es pot fusionar. La vostra protecció de branca determina les comprovacions, les revisions i altres condicions requerides. La fusió autònoma no evita aquestes regles.

Si una revisió automatitzada ha de bloquejar la fusió, feu que el seu resultat sigui una comprovació d’estat requerida mitjançant la configuració admesa pel repositori. Un resultat orientatiu no es converteix en obligatori perquè espereu que ho sigui.

Comproveu també les aprovacions humanes requerides. Una comprovació en verd no substitueix una aprovació que exigeix la vostra política. Confirmeu les regles de la branca de destinació real.

Interpreteu una fusió aturada

Llegiu el motiu a la iniciativa. Una comprovació pendent, una aprovació absent, un conflicte i un pla incomplet requereixen respostes diferents. Taiga també atura la fusió autònoma quan les correccions canvien els criteris que han fet que se superin comprovacions abans fallides. Reviseu directament aquest canvi.

No elimineu una comprovació requerida només perquè bloqueja el progrés. Si la comprovació no informa mai del resultat, corregiu-ne la configuració o feu servir el procés de política autoritzat. Examineu el commit actual després de qualsevol correcció.

Manteniu separada l’autorització de desplegament

L’aplicació Taiga GitHub App fa la fusió autònoma i queda registrada com a responsable de la fusió. El pipeline del repositori conserva el seu comportament de desplegament existent.

En aquest escenari, la fusió desplega a preproducció. Producció continua requerint la decisió de producció i les evidències de l’organització. Confirmeu que el pipeline fa complir aquesta separació. Continueu amb la revisió del lliurament.