เลือกจุดที่ Taiga ต้องรอการตัดสินใจ

แยกการตัดสินใจสี่เรื่อง

บริการขออุปกรณ์สมมติมีการตัดสินใจสี่เรื่องที่แยกกัน ได้แก่ ยอมรับแผน ทำ build, merge การเปลี่ยนแปลง และ deploy อย่าถือว่าสวิตช์เดียวอนุญาตทั้งสี่เรื่อง

ก่อนเปลี่ยนระดับอิสระ ให้ตรวจว่า pipeline ของ repository ทำอะไรหลัง merge หากการ merge เข้า branch ที่ใช้ทำงานกระตุ้น deployment การ merge อัตโนมัติก็อาจกระตุ้น workflow เดิมนั้นด้วย

ตัดสินใจว่าแผนต้องรอหรือไม่

การตั้งค่าผลิตภัณฑ์ Build on its own by default ควบคุมว่าแผนที่เสร็จแล้วเริ่ม build ต่อหรือรออนุมัติ ปิดการตั้งค่านี้เมื่อแผนต้องให้มนุษย์ตัดสินใจก่อน

การตั้งค่า Build on its own ของ initiative สามารถเปลี่ยนพฤติกรรมนี้สำหรับ initiative แต่ละรายการได้ ตรวจทั้งค่าเริ่มต้นและตัวเลือกเฉพาะก่อนใส่งานในคิว

Approve เริ่ม build ในนามผู้อนุมัติ โดยอยู่ภายใต้สิทธิ์ปัจจุบันของผู้นั้น แผนที่ล้มเหลวจะไม่เริ่ม build การทำ build อัตโนมัติไม่ได้อนุญาตให้ merge pull request ที่ได้โดยตัวมันเอง

เข้าใจลำดับชั้นของสิทธิ์ merge

การ merge อัตโนมัติควบคุมแยกต่างหาก และปิดอยู่จนกว่าจะเปิดใช้ Integration ตามเอกสารรองรับ GitHub รวมถึง GitHub Enterprise

ระดับล่างไม่สามารถเปิดสิ่งที่เพดานสิทธิ์ระดับองค์กรหรือโรงงานปิดไว้ แต่ค่าเริ่มต้นของผลิตภัณฑ์ที่ปิดอยู่ต่างกัน: initiative สามารถเปิด merge ของตนเองได้หากเพดานสิทธิ์อนุญาต

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

ทำให้การตรวจทานที่จำเป็นถูกบังคับใช้ได้

Taiga ถามผู้ให้บริการควบคุมเวอร์ชันว่า pull request สามารถ merge ได้หรือไม่ การป้องกัน branch ของคุณกำหนด check การตรวจทาน และเงื่อนไขอื่นที่จำเป็น การ merge อัตโนมัติไม่ข้ามกฎเหล่านี้

หากผลการตรวจทานอัตโนมัติต้องขัดขวางการ merge ได้ ให้กำหนดผลนั้นเป็น status check ที่บังคับผ่านการตั้งค่าที่ repository รองรับ ผลที่ให้คำแนะนำไม่ได้กลายเป็นข้อบังคับเพียงเพราะคุณคาดหวังเช่นนั้น

ตรวจการอนุมัติจากมนุษย์ที่จำเป็นด้วย Check ที่ผ่านไม่แทนที่การอนุมัติที่ policy กำหนด ยืนยันกฎบน branch ปลายทางจริง

ตีความเหตุผลที่หยุด merge

อ่านเหตุผลบน initiative Check ที่ยังรอ การอนุมัติที่ขาด conflict และแผนที่ไม่ครบต้องใช้วิธีจัดการต่างกัน Taiga ยังหยุด merge อัตโนมัติเมื่อการแก้ไขเปลี่ยนเกณฑ์จนทำให้ check ที่เคยไม่ผ่านกลับผ่าน ตรวจทานการเปลี่ยนแปลงนั้นโดยตรง

อย่าลบ check ที่บังคับเพียงเพราะขัดขวางความคืบหน้า หาก check ไม่รายงานผลเลย ให้แก้การตั้งค่าหรือใช้กระบวนการตาม policy ที่อนุญาต ตรวจ commit ปัจจุบันหลังแก้ไขทุกครั้ง

แยกอำนาจอนุมัติ deployment ไว้ต่างหาก

Taiga GitHub App เป็นผู้ทำ merge อัตโนมัติและถูกบันทึกเป็นผู้ merge Pipeline ของ repository ยังคงพฤติกรรมการ deploy เดิม

ในสถานการณ์นี้ การ merge ทำให้ deploy ไปยัง staging ส่วน production ยังต้องใช้การตัดสินใจและหลักฐานสำหรับ production ขององค์กร ยืนยันว่า pipeline บังคับการแยกนี้ เรียนต่อเรื่อง การตรวจทานการส่งมอบ