ตัดสินใจออก release ด้วยหลักฐาน

ระบุการตัดสินใจให้ชัดเจน

Pipeline ที่ผ่านเป็นหลักฐานจากชุดการตรวจสอบ ไม่ใช่คำอธิบายการตัดสินใจออก release ที่ครบถ้วน ผู้รับผิดชอบต้องรู้ว่าจะเปลี่ยนอะไร ที่ใด และยังมีผลตามมาอะไรเหลืออยู่

สำหรับการส่งออกข้อมูลลูกค้าในสถานการณ์สมมติ ให้ระบุ commit ที่ยอมรับและ artifact ที่สร้างจาก commit นั้น ระบุสภาพแวดล้อมเป้าหมาย เชื่อมโยง test การตรวจทาน และข้อยกเว้นที่อนุมัติแล้ว รวมการเปลี่ยนข้อมูลหรือโครงสร้างพื้นฐานที่มาพร้อมแอปพลิเคชัน

SSDF ของ NIST ให้แนวปฏิบัติด้านการพัฒนาที่ปลอดภัย ส่วน SLSA provenance ช่วยอธิบายว่า artifact ถูกสร้างอย่างไร ทั้งสองอย่างไม่ได้ทำให้ไม่ต้องตัดสินใจว่า release นี้เหมาะกับบริการนี้หรือไม่ NIST SSDF, SLSA provenance

แยกสามเหตุการณ์ออกจากกัน

Merge นำการเปลี่ยนแปลง source เข้า branch ส่วน deployment นำ artifact เข้าสภาพแวดล้อม การเปิด feature ทำให้ผู้ใช้เข้าถึงพฤติกรรมนั้นได้ เหตุการณ์เหล่านี้อาจเกิดพร้อมกัน แต่ไม่จำเป็นต้องเป็นเหตุการณ์เดียวกัน

บริการสามารถ deploy feature ที่ยังไม่เปิดใช้งาน แล้วเปิดให้ใช้ภายหลัง Database migration อาจกระทบ production ก่อนที่ feature จะปรากฏต่อผู้ใช้ กำหนดลำดับจริง แทนการสันนิษฐานว่าการ merge PR อธิบายผลตามมาทุกอย่าง

สำหรับการส่งออกข้อมูล feature flag อาจจำกัดการเปิดใช้ช่วงแรก แต่ไม่ได้ป้องกัน endpoint ใหม่หรือย้อน schema migration โดยอัตโนมัติ ตรวจสอบมาตรการควบคุม ณ จุดที่เกิดผลตามมา

ตรวจทานบันทึกหลักฐานที่กระชับ

ใช้บันทึกที่ผู้รับผิดชอบคนอื่นตรวจสอบได้:

• วัตถุประสงค์และผู้ใช้ที่ได้รับผลกระทบ
• Commit และข้อมูลระบุ artifact
• การตรวจสอบพฤติกรรม ความปลอดภัย และ compatibility ที่เกี่ยวข้อง
• สภาพแวดล้อมเป้าหมายและตัวตนที่ใช้ดำเนินการ
• ข้อยกเว้นที่เหลือ พร้อมผู้รับผิดชอบและเงื่อนไขสิ้นสุด
• Monitoring วิธีกู้คืน และผู้รับผิดชอบการตอบสนอง

ระบุข้ออ้างให้เจาะจง “Test ผ่าน” ให้หลักฐานน้อยกว่าลิงก์ผลของ release commit พร้อมคำอธิบายขอบเขตที่ตรวจสอบ “มี rollback” ให้หลักฐานน้อยกว่าขั้นตอนที่ทดสอบแล้วพร้อมข้อจำกัดที่ระบุ

ตัดสินใจว่าจะหยุดอย่างไร

กำหนดเงื่อนไข release ก่อนดำเนินการ สำหรับการส่งออกข้อมูลในสถานการณ์สมมติ ให้หยุดหากเข้าถึงข้อมูลข้ามองค์กรได้ หาก artifact ไม่ตรงกับค่า digest ที่ยอมรับ หรือหากกู้คืนไม่ได้ เงื่อนไขเหล่านี้เป็นตัวอย่าง ไม่ใช่ checklist สำหรับทุกกรณี

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

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

เก็บรักษาการตัดสินใจหลังออก release

บันทึก artifact ที่ deploy จริงและผลลัพธ์ หากการดำเนินการต่างจากแผน ให้แสดงความต่างนั้นอย่างชัดเจน นำ incident และงานที่ไม่คาดคิดไปใช้ในการออกแบบ release ถัดไป

ระบบส่งมอบอัตโนมัติควรทำให้ตรวจสอบบันทึกนี้ง่ายขึ้น ผู้ตรวจทานไม่ควรต้องประกอบเรื่องราวของ release ขึ้นใหม่จากแชต log และภาพหน้าจอที่ไม่เชื่อมกัน หลักฐานที่ชัดเจนช่วยให้ทีมทำงานประจำโดยอัตโนมัติ และยังระบุผู้รับผิดชอบการตัดสินใจได้