เส้นทาง 07บทเรียน 6 / 8

ตรวจทานการส่งมอบจาก Taiga ด้วยหลักฐาน

เชื่อม initiative แผน run, diff และ check ตรวจสอบการเปลี่ยนแปลงปัจจุบันก่อนยอมรับการตัดสินใจ merge หรือ release

ผู้ปฏิบัติงาน11 minตรวจทานแล้ว 5 ต.ค. 2569

เผยแพร่โดย Taigaวิธีเขียนเนื้อหาของเรา

ตรวจความเข้าใจRun เสร็จแล้ว แต่บันทึกระบุว่า test ที่จำเป็นไม่ได้รัน การเสร็จของ run ยืนยันอะไรทำแบบฝึกหัด

แสดงคำตอบ

ตรวจ check ที่ขาดและหาหลักฐานที่จำเป็นก่อนยอมรับพฤติกรรมที่ได้รับผลกระทบ

สิ่งที่จะได้เรียนรู้

ติดตามพฤติกรรมที่ส่งมอบกลับไปยังข้อกำหนดและแผน
ระบุ check ที่ไม่ครบและสมมติฐานที่ต้องตรวจทาน
แยก run ที่เสร็จแล้ว การ merge การ deploy และการที่ผู้ใช้ใช้งานได้ออกจากกัน

เริ่มจากผลลัพธ์ของ initiative

บริการขออุปกรณ์สมมติให้พนักงานดูคำขอของตนเองได้แล้ว เริ่มตรวจทานจากผลลัพธ์และขอบเขตของ initiative ระบุสิ่งที่ต้องเป็นจริงและสิ่งที่การเปลี่ยนแปลงต้องรักษาไว้

ในการส่งมอบนี้ พนักงานต้องอ่านคำขอของพนักงานคนอื่นไม่ได้ ผู้จัดการต้องยังมีสิทธิ์เข้าถึงตามที่กำหนด Test ที่เพียงเปิดหน้าเว็บไม่ได้ยืนยันเงื่อนไขใดในสองข้อนี้

เชื่อมโยงบันทึก

บันทึก	คำถามสำหรับการตรวจทาน
Initiative	อนุญาตผลลัพธ์และขอบเขตใดไว้
เวอร์ชันแผน	ตั้งใจใช้ขั้นตอนพัฒนาและตรวจสอบใด
Run	เกิดอะไรขึ้น และ agent ตั้งสมมติฐานอะไร
Pull request และ diff	Commit ปัจจุบันเปลี่ยนอะไร
Check และการตรวจทาน	หลักฐานใดสนับสนุนการยอมรับ commit นั้น
บันทึก deployment	Artifact ใดไปถึง environment ใด

หน้า Runs บันทึกการทำงานแต่ละครั้ง รวมถึงครั้งที่ล้มเหลว แต่ละ run ระบุแผนที่ใช้ หน้า run เป็นบันทึกสำหรับตรวจสอบ ส่วนการตัดสินใจที่เปลี่ยนงานต้องทำบน initiative

อ่านหลักฐานของขั้นตอน test และการจัดรูปแบบ Taiga แสดง check ที่ไม่ผ่านหรือไม่ได้รันอย่างชัดเจน อย่าเปลี่ยน “ไม่ได้รัน” เป็น “ผ่าน” ในสรุปการตรวจทาน

ตรวจสมมติฐานและขอบเขต

มองหาสมมติฐานเกี่ยวกับรูปแบบสิทธิ์เข้าถึง schema, environment และบริการภายนอก เปรียบเทียบกับเจตนาที่เผยแพร่แล้วและโค้ดจริง

สำหรับบริการขออุปกรณ์ ให้ตรวจว่าตรวจสอบเจ้าของคำขอที่ใด ทดสอบคำขอที่ได้รับอนุญาต คำขอของพนักงานคนอื่น และคำขอที่ไม่มีอยู่ ตรวจว่า log ไม่เผยเนื้อหาคำขอที่เป็นความลับ

ตรวจทานการแก้ test ด้วย ผลที่ผ่านมีคุณค่าจำกัดหากการแก้ไขลบ assertion ที่จะตรวจพบข้อบกพร่อง ถือว่าการเปลี่ยน workflow และการตั้งค่า test เป็นส่วนหนึ่งของขอบเขตการตรวจทาน

ให้ข้อเสนอแนะที่นำไปแก้ไขได้

ระบุพฤติกรรม ผลที่คาดหวัง และหลักฐานที่ต้องการ ตัวอย่าง: “Endpoint ตรวจการเข้าสู่ระบบ แต่ไม่ตรวจเจ้าของคำขอ เพิ่มการตรวจสิทธิ์ฝั่ง server และ test ที่ใช้คำขอของพนักงานคนอื่น”

Taiga สามารถตอบสนองต่อข้อเสนอแนะในการตรวจทาน pull request และ check ที่ไม่ผ่านด้วยการแก้ไขบน branch เดิม หลังอัปเดต ให้ตรวจ commit ใหม่และ check ของมัน หลักฐานเดิมอาจไม่ครอบคลุม artifact ที่เปลี่ยนแล้ว

หาก run หยุดเพราะแผนไม่ครบหรือ check ถูกลดความเข้มงวด ให้อ่านเหตุผลที่ระบุ อย่ายกเลิกสถานะ draft เพียงเพราะสรุป check ที่เห็นแสดงว่าผ่าน

ตัดสินใจยอมรับงานให้ถูกต้อง

บันทึกว่าเกณฑ์ใดได้รับการตรวจสอบแล้ว และเกณฑ์ใดยังไม่ได้ข้อยุติ ให้การตรวจทานและ check ที่ repository บังคับใช้ควบคุมขอบเขตการ merge รักษาการตัดสินใจ release แยกไว้ตามที่จำเป็น

Taiga ติดตาม deployment ที่ pipeline ของคุณดำเนินการ ตรวจสอบ environment และ artifact ก่อนบอกผู้ใช้ว่าการเปลี่ยนแปลงพร้อมใช้แล้ว Deployment ที่ล้มเหลวอาจทำให้เวอร์ชันก่อนหน้าที่สำเร็จยังให้บริการ traffic ต่อ

ปิดงานด้วยการตรวจระดับบริการ: พนักงานใช้ feature ได้ การเข้าถึงที่ไม่ได้รับอนุญาตถูกปฏิเสธ และผู้รับผิดชอบการดำเนินงานมองเห็นความล้มเหลวได้ เรียนต่อเรื่อง การจัดการเมื่องานหยุดรอ

ทำแบบฝึกหัด

การเปลี่ยนสิทธิ์เข้าถึงของพนักงานในสถานการณ์สมมติมี build ที่ผ่าน และบันทึก run ระบุว่า integration test หนึ่งรายการรันไม่ได้ เขียนหลักฐานที่ต้องมีก่อนยอมรับงาน รวมกรณีปฏิเสธการเข้าถึงหนึ่งกรณี และ artifact หรือ commit ที่กำลังตรวจทานอย่างเจาะจง

ดาวน์โหลดใบงาน (Markdown)

ตรวจความเข้าใจ ↑