เมื่อใดที่เหมาะสมที่จะเริ่มใช้การแก้ไขครั้งต่อไปของเครื่องมือเมื่อทำการทดลองอาหาร

โดยเฉพาะฉันกำลังทำงานกับเครื่องมือที่รวม DVCS และระบบการสร้าง แต่ฉันนึกภาพความท้าทายที่ฉันกำลังเผชิญจะเกิดขึ้นสำหรับทุกคนที่พัฒนาเครื่องมือ "เมตา" (คอมไพเลอร์ VCS ระบบสร้างตัวทดสอบวิ่ง ฯลฯ ) ต้องการพัฒนาผ่านการ"ทดลองใช้"

คำถามของฉันคือในกระบวนการปล่อยรูปแบบการต่อสู้โดยใช้เวิร์กโฟลว์การแยกที่จุดใดฉันจะเริ่มใช้เครื่องมือรุ่นที่ใหม่กว่าในวงจรการพัฒนาของเครื่องมือได้หรือไม่

ฉันกำลังมองหากระบวนการสร้างความสมดุลระหว่าง:

• ใช้developเวอร์ชันของเครื่องมืออย่างต่อเนื่อง: ฉันพบว่าฉันเลิกพัฒนาตนเองเมื่อมีการเปลี่ยนแปลงเกิดขึ้น

• ใช้masterเวอร์ชันของเครื่องมืออย่างต่อเนื่อง: ปัญหาใด ๆ ที่ฉันค้นพบผ่านการทดลองใช้สุนัขเป็นปัญหาที่ได้รับการเผยแพร่แล้ว

สิ่งแรกที่ต้องทำคือมีการทดสอบการถดถอยออฟไลน์อัตโนมัติอย่างละเอียดมาก ทำให้การทดสอบเหล่านั้นผ่านข้อกำหนดขั้นต่ำสำหรับสิ่งที่คุณใช้อย่างเป็นทางการ

ประการที่สองคุณต้องมีวิธีง่าย ๆ ในการถอยกลับไปใช้งานเวอร์ชันก่อนหน้าสำหรับปัญหาที่การทดสอบอัตโนมัติของคุณไม่ทัน

ตัวอย่างเช่นเคอร์เนล Linux ของฉันได้รับการติดตั้งแบบกำหนดเองเป็นระยะเวลาหนึ่ง ฉันจะแก้ไขและรวบรวมเคอร์เนลของฉันบนคอมพิวเตอร์เครื่องเดียวกันฉันตั้งใจจะใช้มันซึ่งหมายความว่าฉันอาจสูญเสียสภาพแวดล้อมการพัฒนาของฉันถ้าฉันสร้างเคอร์เนลผิดพลาด ดังนั้นฉันจึงมั่นใจว่าจะรักษาเคอร์เนลที่ดีอยู่เสมอในเมนูด้วงของฉันดังนั้นถ้าฉันทำผิดพลาดฉันก็กลับไปที่สภาพแวดล้อมการพัฒนาที่ดีด้วยการรีบูตง่าย

การประสานงานกับทีมนั้นยุ่งยาก แต่ฉันคิดว่ามันเป็นเรื่องของการอนุญาตให้ทุกคนเริ่มต้นทางเลือกและสื่อสารถึงเหตุผล ในการควบคุมเวอร์ชันวิธีหนึ่งในการกำหนดว่าจะเป็นกับlast_known_goodสาขาใดสาขาหนึ่งระหว่างdevelopและmasterในเวิร์กโฟลว์ของคุณ ไม่มีอะไรผลักไปที่นั่นจนกว่าคุณจะประสบความสำเร็จในการสร้างโครงสร้าง

หากเครื่องมือนี้ถูกใช้เพื่อผลิตซอฟต์แวร์ที่มีคุณภาพการผลิต (โดยเฉพาะอย่างยิ่งถ้ามันถูกใช้ซ้ำ ๆ เพื่อพัฒนาตัวเอง) ฉันจะเพิ่มความพยายามในการทดสอบล่วงหน้าของคุณและรอ dogfooding จนกว่าการปล่อยจะเสถียรพอที่คุณจะ ค่อนข้างมั่นใจว่าคุณจะไม่ได้ทำลายรหัสการผลิตโดยใช้มัน

หากคุณต้องรอให้เวอร์ชันหลักมีระดับความเชื่อมั่นนั้น

Git ยังเป็นเครื่องมือดังกล่าวและเห็นได้ชัดว่ายังทำอาหารสุนัข แต่มันจะแตกต่างกันในสภาพแวดล้อมที่แตกต่างกัน เซิร์ฟเวอร์สาธารณะใช้งานได้เฉพาะในขณะที่นักพัฒนามักจะทำงานร่วมกับnext(นั่นคือชื่อของโครงการคอมไพล์สำหรับ "พัฒนา") หรือpu(พัฒนาได้มากกว่าการพัฒนา) นักพัฒนาซอฟต์แวร์ใด ๆ ที่ถูกบล็อกโดยปัญหาบางอย่างสามารถกลับไปที่nextหรือmasterหรือปล่อยครั้งสุดท้ายเมื่อใดก็ตามที่พวกเขาถูกบล็อกโดยบางสิ่งบางอย่างและพื้นที่เก็บข้อมูลหลักไม่ได้รับผลกระทบดังนั้นปัญหาสามารถทำความสะอาดได้โดยอ้างอิง

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

มีสาขาพิเศษ, pu. สิ่งนี้สร้างขึ้นโดยการรวมสาขาฟีเจอร์ทั้งหมดที่ได้รับการพิจารณาสำหรับการรวมเข้าด้วยกันnext(สาขาจะถูกยกเลิกและสร้างใหม่ในแต่ละครั้ง) IIRC เผยแพร่เมื่อมันผ่านชุดทดสอบเท่านั้น ครั้งล่าสุดที่ฉันดู Junio ​​ผู้ดูแลกำลังเรียกใช้สคริปต์เพื่อสร้างสคริปต์เป็นประจำ แต่สคริปต์ดังกล่าวสามารถทำงานได้โดยรวมอย่างต่อเนื่องทุกคืนและฉันเชื่อว่าGerritจะสร้างมันขึ้นมาโดยอัตโนมัติ

ดังนั้นคำตอบก็คือ คุณทดลองใช้เวอร์ชันการพัฒนาส่วนใหญ่ที่คุณมีในสภาพแวดล้อมการพัฒนา แต่ให้ใช้รุ่นก่อนหน้าสำหรับการสร้างรีลีส

จากคำตอบที่ได้รับการยอมรับฉันจะขยายเวิร์กโฟลว์การแยกเพื่อรักษาสาขาที่คล้ายกับดังต่อไปนี้:

• master: ผสานกับrelease-*เมื่อปิด
• dogfood: สาขาจากmaster; รวมถึงการแก้ไขที่ระบุในขณะที่ dogfooding; ผสานจากdevelopเมื่อซอฟต์แวร์ถือว่า "เสถียร" สำหรับการใช้งานภายใน หัวของสาขานี้สามารถย้ายกลับในเวลาถ้าจำเป็น
• develop: สาขาจากmaster; รวมถึงการเปลี่ยนแปลงอย่างต่อเนื่องการแก้ไขข้อบกพร่องและการรวมจากdogfoodและfeature-*สาขา
• feature-*: สาขาจากdevelop; รวมถึงการเปลี่ยนแปลงคุณสมบัติใหม่โดยเฉพาะ
• release-*: แยกจากdogfoodเมื่อซอฟต์แวร์ถูกพิจารณาว่า "เสถียร" สำหรับการใช้งานภายนอก รวมถึงการอัปเดตเอกสารประกอบและข้อผิดพลาดเล็กน้อยก่อนที่จะผสานเข้าด้วยกันmaster