บริษัท ของฉันรวมสาขาผิดหรือเปล่า?

ฉันเพิ่งมาข้ามบทความ MSDN เกี่ยวกับการแยกทางและการผสานและ SCM: การแตกแขนงและผสานรองพื้น - คริส Birmele

ในบทความพวกเขาบอกว่า 'บิ๊กแบงผสาน' เป็นปฏิปักษ์ต่อการรวม:

Big Bang Merge - ชะลอการรวมสาขาเพื่อสิ้นสุดความพยายามในการพัฒนาและพยายามรวมสาขาทั้งหมดพร้อมกัน

ฉันรู้ว่านี่คล้ายกับสิ่งที่ บริษัท ของฉันทำกับสาขาการพัฒนาทั้งหมดที่ผลิต

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

เจ้านายของฉันซึ่งเป็นผู้มีอำนาจ แต่เพียงผู้เดียวในที่เก็บ trunk จะทำการตรวจสอบความคิดเห็นทั้งหมดของสาขาจนกว่าจะถึงจุดเดียวในเวลาที่เขาจะแสดงความคิดเห็นให้มากที่สุดเท่าที่จะทำได้บางสาขาจะถูกโยนทิ้งเพื่อปรับปรุง / แก้ไข กิ่งไม้จะถูกรวมเข้ากับลำต้นบางสาขาจะถูกโยนกลับเนื่องจากความขัดแย้ง ฯลฯ

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

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

บางคำถามโดยตรงฉัน:

• พวกเราแสดงรูปแบบการต่อต้านที่ถูกอธิบายว่าเป็น 'บิ๊กแบงผสาน' หรือไม่?
• ปัญหาบางอย่างที่เราเห็นเป็นผลมาจากกระบวนการผสานนี้หรือไม่
• เราจะปรับปรุงกระบวนการผสานนี้โดยไม่เพิ่มคอขวดในเจ้านายของฉันได้อย่างไร

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

ข้อมูลเชิงลึกอื่น ๆ เกี่ยวกับสถานการณ์นี้จะได้รับการชื่นชม

ข้อเสนอแนะบางส่วน:

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

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

• วิธีนี้จะทำงานได้ดีขึ้นถ้าผู้รักษาประตูไม่รอจนกว่า 10 สาขาจะ "พร้อมสำหรับการรวมเข้ากับลำต้น" - การแก้ไขข้อขัดแย้งการผสานจากการรวมตัวของลำตัวสุดท้ายมักต้องการเวลาสำหรับทีมดังนั้นจึงควรทำงานในช่วงเวลา interwoven - การรวมหนึ่งครั้งโดยผู้รักษาประตู, การรวมกันอีกครั้งของทีม, การรวมครั้งต่อไปโดยผู้รักษาความปลอดภัย, การรวมกันอีกครั้งโดยทีมและอื่น ๆ

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

• ไม่ช้าก็เร็วคุณจะพบกับการ refactoring งานที่ส่งผลกระทบต่อไฟล์จำนวนมากในฐานรหัส - เหล่านี้มีความเสี่ยงสูงที่ทำให้เกิดความขัดแย้งผสานจำนวนมากกับสาขาต่างๆ สิ่งเหล่านั้นสามารถจัดการได้ดีที่สุดโดยการสื่อสารพวกเขาอย่างชัดเจนในทีมและตรวจสอบให้แน่ใจว่าได้จัดการพวกเขาตรงตามที่ฉันเขียนไว้ข้างต้น: โดยการรวมพวกเขาเข้ากับทุกสาขา dev ก่อน reintegration และแยกพวกมันออกเป็นย่อยย่อย

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

พวกเราแสดงรูปแบบการต่อต้านที่ถูกอธิบายว่าเป็น 'บิ๊กแบงผสาน' หรือไม่?

ฟังดูเหมือนมัน

ปัญหาบางอย่างที่เราเห็นเป็นผลมาจากกระบวนการผสานนี้หรือไม่

อย่างแน่นอน

เราจะปรับปรุงกระบวนการผสานนี้โดยไม่เพิ่มคอขวดในเจ้านายของฉันได้อย่างไร

ที่ บริษัท ของฉัน dev ทุกคนมีความสามารถในการผสาน เรากำหนดคำขอผสานให้กับผู้พัฒนารายอื่นผ่านขั้นตอนการตรวจสอบ / ตอบกลับ / อัปเดตจนกว่าทั้งสองฝ่ายจะพอใจ จากนั้นผู้ตรวจทานจะรวมรหัส

10-20 สาขาที่รอการผสานเป็นสัญญาณว่ากระบวนการของคุณมีข้อบกพร่อง หากเรามีจำนวนมากงาน dev ทั้งหมดจะหยุดจนกว่าจะหมดลง

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

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

ฉันเห็นด้วยกับ Doc Brown ทั้งคู่ แต่ฉันก็เห็นอีกฝ่าย:

เจ้านายของฉันซึ่งเป็นผู้มีอำนาจ แต่เพียงผู้เดียวในที่เก็บ trunkจะทำการตรวจสอบความคิดเห็นทั้งหมดของสาขาจนกว่าจะถึงจุดเดียวในเวลาที่เขาจะแสดงความคิดเห็นให้มากที่สุดเท่าที่จะทำได้สาขาบางแห่งจะถูกโยนทิ้งเพื่อปรับปรุง / แก้ไข กิ่งไม้จะถูกรวมเข้ากับลำต้นบางสาขาจะถูกโยนกลับเนื่องจากความขัดแย้งฯลฯ

ในความต่ำต้อยของฉันมีกลุ่มต่อต้านการบริหารจัดการ:

1. เขา / เธอเป็นจุดที่ทำให้หายใจไม่ออก จำกัด ความเร็วของทีม ปัจจัยบัสของคุณคือ 1 ทฤษฎีข้อ จำกัดบอกว่าคุณควรใช้ความพยายามในการปรับปรุงส่วนที่ช้าที่สุดของโซ่
2. ผู้จัดการของคุณกำลังทำให้วงจรความคิดเห็นของคุณช้าลงและลดความว่องไวของทีมของคุณ คุณสามารถปล่อยทุกสัปดาห์ได้หรือไม่
3. การรวมความซับซ้อนเพิ่มขึ้นแบบทวีคูณด้วยจำนวนของรหัส เป็นการดีกว่าที่จะทำการรวม 10 เส้นกับ 100 บรรทัดกว่า 1 จาก 1,000 บรรทัด นั่นเป็นเพียงหนึ่งในเหตุผลที่คุณควรทำโดยเร็วที่สุด
4. หากคุณตรวจพบความล้มเหลวในลำต้นคุณจะทำมันในเวลา สาขาไหนเป็นสาขาที่มีปัญหา
5. การตัดสินใจควรทำโดยผู้ที่มีความรู้เกี่ยวกับพวกเขามากขึ้น ใครจะรู้เพิ่มเติมในกรณีนี้ ฉันเดิมพันว่านักพัฒนาที่ทำรหัส
6. คุณไม่สามารถแก้ไขข้อผิดพลาดในการผลิตได้หากผู้จัดการของคุณเป็นแบบโฮลิดเดย์
7. คุณกำลังทำงานซ้ำและทิ้งสาขา นี่เป็นการเสียเวลา เวลาที่ใช้ในการรอคอยเพื่อไปถึงการผลิตก็เป็นของเสีย

recomendations:

• ผู้จัดการของคุณต้องมอบหมายความรับผิดชอบให้กับทีม คุณต้องแสดงให้เห็นว่าทีมนั้นมีความเป็นมืออาชีพ ทำให้ชัดเจนว่าพวกเขาสามารถไว้วางใจในทีมได้
• ใช้วิธีการตรวจสอบบางอย่าง อาจเป็นเพราะคุณต้องการคะแนนเฉลี่ยของสมาชิกในทีมอีกสองคน
• อาจจะใช้ SVN ทำให้มันยากขึ้น ลอง Git และดูว่ามันช่วยคุณได้ไหม มากไปกว่านั้น. หากคุณใช้ GitHub คุณสามารถใช้กลไกคำขอดึงเพื่อให้การผสานต้องใช้การลงคะแนนแน่นอน
• อ่านและแบ่งปันข้อมูลเกี่ยวกับการปฏิบัติที่คล่องตัวรวมอย่างต่อเนื่องและ DevOps

เมื่อคุณทำงานคุณลักษณะในสาขาแยกคุณจะไม่สามารถทำการทดสอบการรวมกันได้อย่างง่ายดายจนกว่าสาขาใดสาขาหนึ่งจะถูกรวมเข้ากับลำตัวและดึงเข้าไปในสาขาคุณลักษณะอื่น ๆ จากประสบการณ์ของฉันนี่เป็นปัญหาหลักของรูปแบบการต่อต้านของ Big Bang Merge เป็นการดีที่คุณจะทำงานคุณสมบัติทดสอบในสาขาคุณสมบัติรวมไว้ในลำต้นและ ณ จุดที่คุณทำกับคุณสมบัติ หากยังไม่ได้รับการรวมคุณต้องกลับมาดูอีกครั้งทุกครั้งที่มีสิ่งอื่นเข้ามารวมอยู่ในลำตัวก่อนหน้า ความเจ็บปวดของรูปแบบการต่อต้านนี้คือคุณมีบั๊กประเภทการรวมจำนวนมากปรากฏขึ้นเมื่อสิ้นสุดรอบการพัฒนา

ดังนั้นคุณมี 20 สาขา สาขา 1 ถูกรวมเข้าด้วยกัน จากนั้นผู้พัฒนาของสาขา 2 จะต้องรวมสาขา 1 เข้ากับสาขาของตนเพื่อให้สามารถผสานเข้ากับหลักโดยไม่มีข้อขัดแย้งจากนั้นผสาน จากนั้นผู้พัฒนาของสาขา 3 จะต้องรวมสาขา 1 และสาขา 2 เข้ากับสาขาของตนเพื่อให้สามารถผสานเข้ากับหลักโดยไม่มีข้อขัดแย้งจากนั้นผสาน

การออกกำลังกายสำหรับผู้อ่าน: เขียนโปรแกรมที่พิมพ์โพสต์ที่สมบูรณ์ของฉัน :-)

นี่คือความบ้า. คุณจะใช้เวลารวมกันอย่างไม่น่าเชื่อ

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

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