Reviseu un lliurament de Taiga amb evidències

Comenceu pel resultat de la iniciativa

El servei fictici d’equipament ara permet als empleats veure les seves pròpies sol·licituds. Comenceu la revisió pel resultat i l’abast de la iniciativa. Identifiqueu què ha de ser cert i què ha de deixar intacte el canvi.

En aquest lliurament, un empleat no ha de poder llegir la sol·licitud d’un altre. Els responsables han de conservar l’accés definit. Una prova que només obre la pàgina no demostra cap d’aquestes condicions.

Connecteu els registres

La pàgina Runs registra els intents, incloses les fallades. Cada execució identifica el pla que ha executat. Una pàgina d’execució és un registre per examinar; les decisions que canvien la feina corresponen a la iniciativa.

Llegiu les evidències dels passos de proves i format. Taiga fa visibles les comprovacions fallides o no executades. No convertiu «no executada» en «superada» al resum de revisió.

Examineu les hipòtesis i els límits

Busqueu hipòtesis sobre el model d’accés, l’esquema, l’entorn i els serveis externs. Compareu-les amb la intenció publicada i el codi real.

Per al servei d’equipament, examineu on es comprova el propietari de la sol·licitud. Proveu una sol·licitud a la qual l’usuari té accés autoritzat, una d’un altre empleat i una sol·licitud inexistent. Comproveu que els registres d’activitat no revelin contingut confidencial de les sol·licituds.

Reviseu també els canvis de les proves. Un resultat superat té un valor limitat si el canvi ha eliminat l’asserció que detectaria el defecte. Incloeu els canvis del flux de treball i de la configuració de proves dins de l’abast de revisió.

Doneu comentaris que permetin actuar

Identifiqueu el comportament, el resultat esperat i les evidències necessàries. Per exemple: «L’endpoint comprova l’inici de sessió, però no qui és el propietari de la sol·licitud. Afegiu la comprovació d’accés al servidor i una prova amb la sol·licitud d’un altre empleat.»

Taiga pot respondre als comentaris de revisió de la pull request i a les comprovacions fallides amb canvis a la mateixa branca. Després de les actualitzacions, examineu el nou commit i les seves comprovacions. Les evidències anteriors poden no cobrir un artefacte modificat.

Si l’execució s’ha aturat perquè el pla era incomplet o s’ha afeblit una comprovació, llegiu-ne el motiu. No elimineu l’estat d’esborrany només perquè el resum visible de comprovacions estigui en verd.

Preneu la decisió d’acceptació correcta

Registreu quins criteris estan verificats i quins continuen sense resoldre. Deixeu que les revisions i comprovacions requerides del repositori facin complir el límit de fusió. Preserveu qualsevol decisió de publicació separada.

Taiga observa els desplegaments que fa el vostre pipeline. Verifiqueu l’entorn i l’artefacte abans de dir als usuaris que el canvi està disponible. Un desplegament fallit pot deixar la versió anterior que funcionava servint el trànsit.

Tanqueu el resultat amb una comprovació a nivell de servei: l’empleat pot fer servir la funcionalitat, es denega l’accés no autoritzat i el responsable operatiu pot observar les fallades. Continueu amb gestionar una interrupció.