Alegeți când Taiga așteaptă o decizie

Separați patru decizii

Serviciul fictiv de echipamente presupune patru decizii diferite: acceptarea planului, execuția lui, merge-ul modificării și instalarea acesteia în mediu. Nu tratați un singur comutator ca autorizare pentru toate patru.

Înainte de a schimba autonomia, inspectați ce face pipeline-ul depozitului de cod după merge. Dacă merge-ul în branch-ul de lucru declanșează instalarea, un merge automat poate declanșa și acel flux existent.

Decideți dacă planul așteaptă

Setarea produsului Build on its own by default controlează dacă un plan terminat trece la execuție sau așteaptă aprobarea. Dezactivați-o când planurile necesită mai întâi o decizie umană.

Setarea Build on its own a unei inițiative poate schimba comportamentul pentru acea inițiativă. Inspectați atât setarea implicită, cât și orice alegere specifică înainte de plasarea lucrului în coadă.

Approve începe execuția planului în numele persoanei care aprobă, în limitele permisiunilor sale actuale. Un plan eșuat nu declanșează execuția. Automatizarea execuției nu autorizează singură merge-ul pull request-ului rezultat.

Înțelegeți ierarhia pentru merge

Merge-ul autonom este controlat separat și rămâne oprit până la activare. Integrarea documentată acceptă GitHub, inclusiv GitHub Enterprise.

Dezactivarea la nivelul organizației sau fabricii nu poate fi anulată de un nivel inferior. Setarea implicită dezactivată a produsului este diferită: o inițiativă își poate activa propriul merge dacă limitele superioare permit acest lucru.

Pentru serviciul de echipamente, păstrați explicit domeniul inițial. O inițiativă cu consecințe limitate poate avea o alegere diferită de o modificare a controalelor de acces ale angajaților, în limitele permise.

Impuneți verificările obligatorii

Taiga întreabă furnizorul serviciului de control al versiunilor dacă pull request-ul poate fi integrat prin merge. Protecția branch-ului determină verificările, revizuirile și celelalte condiții obligatorii. Merge-ul autonom nu ocolește aceste reguli.

Dacă o verificare automată trebuie să blocheze merge-ul, transformați rezultatul său într-o verificare de stare obligatorie prin configurația acceptată de depozitul de cod. Un rezultat consultativ nu devine obligatoriu doar pentru că vă așteptați să fie.

Verificați și aprobările umane obligatorii. O verificare încheiată cu succes nu înlocuiește aprobarea cerută de politică. Confirmați regulile branch-ului țintă efectiv.

Interpretați un merge oprit

Citiți motivul afișat pe inițiativă. O verificare în așteptare, o aprobare lipsă, un conflict și un plan incomplet necesită răspunsuri diferite. Taiga oprește merge-ul autonom și când remedierile modifică criteriile astfel încât verificările anterior eșuate ajung să treacă. Verificați direct acea modificare.

Nu eliminați o verificare obligatorie doar pentru că blochează progresul. Dacă verificarea nu raportează niciodată un rezultat, corectați configurația sau folosiți procesul autorizat al politicii. Inspectați commit-ul actual după orice remediere.

Păstrați separat autorizarea instalării

Aplicația Taiga pentru GitHub efectuează merge-ul autonom și este înregistrată ca autor al merge-ului. Pipeline-ul depozitului de cod păstrează comportamentul existent de instalare.

În acest scenariu, merge-ul instalează în staging. Producția necesită în continuare decizia și dovezile de producție ale organizației. Confirmați că pipeline-ul impune această separare. Continuați cu verificarea livrării.