Examiner une livraison Taiga à partir de preuves

Partir du résultat de l’initiative

Le service fictif d’équipement permet maintenant aux salariés de voir leurs demandes. Commencez la revue par le résultat et le périmètre de l’initiative. Identifiez ce qui doit être vrai et ce que la modification doit préserver.

Pour cette livraison, un salarié ne doit pas lire la demande d’un autre. Les managers doivent conserver leur accès défini. Un test qui ouvre seulement la page n’établit aucune de ces conditions.

Relier les traces

La page Runs consigne les tentatives, y compris les échecs. Chaque exécution identifie le plan utilisé. Sa page sert à l’examen ; les décisions qui changent le travail se prennent sur l’initiative.

Lisez les preuves des étapes pour les tests et le formatage. Taiga rend visibles les contrôles échoués ou non exécutés. Ne transformez pas « non exécuté » en « réussi » dans votre résumé de revue.

Examiner les hypothèses et les limites

Cherchez les hypothèses sur le modèle d’accès, le schéma, l’environnement et les services externes. Comparez-les à l’intention publiée et au code réel.

Pour le service d’équipement, examinez où le propriétaire de la demande est contrôlé. Testez une demande autorisée, la demande d’un autre salarié et une demande inexistante. Vérifiez que les journaux ne révèlent pas le contenu confidentiel des demandes.

Examinez aussi les modifications des tests. Un résultat réussi a peu de valeur si la modification a supprimé l’assertion qui détecterait le défaut. Incluez les changements de workflow et de configuration des tests dans la revue.

Donner des retours exploitables

Identifiez le comportement, le résultat attendu et les preuves nécessaires. Par exemple : « L’endpoint vérifie la connexion, mais pas la propriété de la demande. Ajoutez le contrôle d’accès côté serveur et un test utilisant la demande d’un autre salarié. »

Taiga peut répondre aux retours de revue de pull request et aux contrôles échoués par des modifications sur la même branche. Après une mise à jour, examinez le nouveau commit et ses contrôles. Les preuves précédentes peuvent ne pas couvrir un artefact modifié.

Si l’exécution s’est arrêtée parce que le plan était incomplet ou qu’un contrôle a été affaibli, lisez la raison indiquée. Ne retirez pas le statut de brouillon simplement parce que le résumé visible des contrôles est vert.

Prendre la bonne décision d’acceptation

Consignez les critères vérifiés et ceux encore non résolus. Laissez les revues et contrôles requis du dépôt imposer la limite du merge. Préservez toute décision de mise en production distincte.

Taiga observe les déploiements effectués par votre pipeline. Vérifiez l’environnement et l’artefact avant d’annoncer aux utilisateurs que la modification est disponible. Un déploiement échoué peut laisser la version précédente réussie servir le trafic.

Terminez par un contrôle au niveau du service : le salarié peut utiliser la fonctionnalité, l’accès non autorisé est refusé et le responsable d’exploitation peut observer les échecs. Poursuivez avec la gestion d’une interruption.