Bizonyítékok alapján vizsgálja felül a Taiga szállítását

Az initiative eredményéből induljon ki

A fiktív eszközigénylő szolgáltatás most már lehetővé teszi, hogy a munkatársak megnézzék saját igényeiket. A review-t az initiative eredményével és hatókörével kezdje. Azonosítsa, minek kell teljesülnie, és mit kell változatlanul hagynia a módosításnak.

Ennél a szállításnál a munkatárs nem olvashatja el egy másik munkatárs igényét. A vezetőknek meg kell tartaniuk meghatározott hozzáférésüket. A teszt, amely csak megnyitja az oldalt, egyik feltételt sem igazolja.

Kapcsolja össze a nyilvántartásokat

A Runs oldal rögzíti a próbálkozásokat, a sikerteleneket is. Minden futás megadja a végrehajtott tervet. A futás oldala vizsgálati nyilvántartás; a munkát módosító döntések az initiative-hez tartoznak.

Olvassa el a tesztek és a formázás lépéseinek bizonyítékait. A Taiga láthatóvá teszi a sikertelen vagy végre nem hajtott ellenőrzéseket. A review összefoglalójában ne változtassa a „nem futott le” állapotot „sikeresre”.

Vizsgálja meg a feltételezéseket és a határokat

Keresse a hozzáférési modellre, sémára, környezetre és külső szolgáltatásokra vonatkozó feltételezéseket. Vesse össze őket a közzétett szándékkal és a tényleges kóddal.

Az eszközigénylő szolgáltatásnál vizsgálja meg, hol ellenőrzi a rendszer az igény tulajdonosát. Teszteljen egy engedélyezett igényhozzáférést, egy másik munkatárs igényét és egy nem létező igényt. Ellenőrizze, hogy a logok nem fednek-e fel bizalmas igénytartalmat.

A tesztmódosításokat is vizsgálja felül. A sikeres eredmény értéke korlátozott, ha a módosítás eltávolította a hibát felismerő ellenőrzést. A munkafolyamatok és a tesztkonfiguráció módosításai is tartozzanak a review hatókörébe.

Adjon végrehajtható visszajelzést

Nevezze meg a működést, az elvárt eredményt és a szükséges bizonyítékot. Például: „Az endpoint ellenőrzi a bejelentkezést, de az igény tulajdonosát nem. Adjon hozzá szerveroldali hozzáférési ellenőrzést és egy másik munkatárs igényét használó tesztet.”

A Taiga ugyanazon a branchen végzett módosításokkal reagálhat a pull request review-visszajelzéseire és a sikertelen ellenőrzésekre. Frissítés után vizsgálja meg az új commitot és ellenőrzéseit. A korábbi bizonyíték nem feltétlenül fedi le a módosult artifactot.

Ha a futás hiányos terv vagy meggyengített ellenőrzés miatt állt le, olvassa el a megadott okot. Ne szüntesse meg a vázlatállapotot pusztán azért, mert a látható ellenőrzési összesítő sikeres.

Hozza meg a megfelelő elfogadási döntést

Rögzítse, mely kritériumokat igazolták, és melyek maradtak megoldatlanok. A repozitár kötelező review-i és ellenőrzései érvényesítsék a merge határát. Őrizze meg a külön kiadási döntést.

A Taiga megfigyeli a pipeline által végzett telepítéseket. Ellenőrizze a környezetet és az artifactot, mielőtt elmondja a felhasználóknak, hogy a módosítás elérhető. Sikertelen telepítés után továbbra is a korábbi sikeres verzió szolgálhatja ki a forgalmat.

Az eredményt szolgáltatásszintű ellenőrzéssel zárja le: a munkatárs használhatja a funkciót, a jogosulatlan hozzáférés tiltott, és az üzemeltetési felelős megfigyelheti a hibákat. Folytassa a megszakítás kezelésével.