วิธีการเปลี่ยนจากความเป็นจริงของการแตกแขนงที่ซับซ้อนไปเป็นรูปแบบสาขาเดียว?

ในองค์กรขนาดใหญ่การใช้วิธีการน้ำตกมักจะส่งผลให้เกิดโครงสร้างการแตกแขนงที่ซับซ้อนมาก (aka spagetti สาขา )

กลยุทธ์การแยกสาขาใดบ้างที่สามารถใช้ในการเปลี่ยนจากความเป็นจริงของการแตกแขนงที่ซับซ้อนไปเป็นโมเดลสาขาเดียวเช่นการพัฒนาแบบอิงลำตัว?

ปรับปรุง:

เพื่อชี้แจงคำถามที่เกี่ยวกับการโยกย้าย / การเปลี่ยนแปลงตัวเองไม่เกี่ยวกับวิธีการก่อนและหลังซึ่งค่อนข้างชัดเจน

ไม่น่าจะเป็น "ที่ EOB วันนี้เรายังคงเป็นน้ำตกที่มีสาขากว่าพันล้านแห่ง แต่พรุ่งนี้สิ่งแรกที่เราจะเปลี่ยนไปใช้ CI แบบสาขาเดียว"

เนื่องจากคุณพูดถึงน้ำตกฉันเข้าใจว่าสาขาต่าง ๆ ที่คุณกำลังพูดถึงนั้นเป็นสาขาสาขามากกว่าสาขาบำรุงรักษา

ในการตั้งค่านี้ฉันยังสมมติว่าสาขาเหล่านี้ถูกสร้างขึ้นตามแผนน้ำตกที่พยายามลดความขัดแย้ง นี่ก็หมายความว่าเป้าหมายของการพัฒนาคือผลิตผลิตภัณฑ์ที่แตกต่างหลากหลาย เมื่อใช้รูปแบบการพัฒนาสาขาเดียวมันเป็นสิ่งสำคัญที่จะทำงานกับผลิตภัณฑ์เดียว ถ้าหลายผลิตภัณฑ์ที่มีการพัฒนาไปพร้อม ๆ กันในการพัฒนารูปแบบเดียวสาขาได้อย่างมีประสิทธิภาพ“กาว” ร่วมรุ่นของผลิตภัณฑ์วิทยานิพนธ์เพื่อที่ว่าเราอาจจะมีในรุ่นของที่เก็บสินค้าที่มีสุขภาพดีXและสินค้าที่มีรถYในขณะที่ในรุ่นBผลิตภัณฑ์XมีการถดถอยและYแก้ไขข้อผิดพลาด แต่เราไม่มีรุ่นที่ทั้งXและYมีสุขภาพดี สถานการณ์ดังกล่าวจะบังคับให้เราพิจารณาXและYว่าได้รับการพัฒนาในที่เก็บที่แตกต่างกันซึ่งเป็นคำใบ้ว่าควรจะเป็น

ดังนั้นขั้นตอนแรกควรทำการแยกที่เก็บ :

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

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

3. เมื่อแต่ละสาขาปฏิบัติตามขั้นตอนที่ 2 ให้ทำการแยก นักพัฒนาสามารถแปลงการเปลี่ยนแปลงที่รอดำเนินการของพวกเขาเพื่อแก้ไขพื้นที่เก็บข้อมูลเดียวเพียงแค่ลบระดับแรกของเส้นทาง

ตอนนี้ได้ดำเนินการแยกแล้วคุณสามารถเริ่มทำงานในสาขาสาขาของตัวเอง

4. แนะนำเทคนิคการเขียนโปรแกรมเพื่อช่วยในการพัฒนาสาขาอายุสั้น สาขาที่มีอายุสั้นเป็นสิ่งสำคัญของวิธีการสาขาเดียวทั้งหมด หนึ่งในเป้าหมายของพวกเขาคือการลดเวลาที่ใช้ในการผสานและแก้ไขข้อบกพร่องสาขาที่มีอายุยืน เทคนิคที่ได้รับความนิยมคือการแนะนำของ "คุณสมบัติ - ธง" ที่ "โรงงาน" ใช้ธงการตั้งค่าคอนฟิกเพื่อสร้างประวัติศาสตร์รุ่นของวัตถุหรือรุ่นใหม่ในขั้นต้นการพัฒนาบางส่วนของวัตถุนั้น

5. ถึงตอนนี้คุณมีที่เก็บของ zillions ที่มีเพียงไม่กี่สาขาในแต่ละแห่งและคุณสามารถเปลี่ยนปุ่ม“ เราใช้ระเบียบวินัยการพัฒนาที่อิงตามช่องทางสากล” โดยไม่เห็นภูเขาสาขาสปาเก็ตตี้ยุบตัวบนลำต้น

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

เมื่อโอนย้ายจากบางสิ่งเป็นอย่างอื่นมีเพียงสองสิ่งที่คุณต้องกำหนด:

1. เป้าหมายของคุณคืออะไร
2. วิธีเดินทาง (แผนการย้ายถิ่น)

ส่วนแรกคือเศร้ามักจะมองข้ามหรือวิธีคลุมเครือเกินไป คุณไม่สามารถพูดได้ว่าสิ่งที่คุณมีเป็นระเบียบและคุณต้องการจัดระเบียบ นั่นหมายความว่าอย่างไร ทุกคนจะมีการตีความที่แตกต่างกัน (aka: dev ทุกคนคิดว่าวิธีการทำสิ่งที่ดีที่สุดของเขาหรือเธอ )

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

ยกตัวอย่างเช่นเป้าหมายของคุณควรจะกำหนดไว้เป็นอย่างชัดเจน Vincent Driessen กำหนดของเขา"ที่ประสบความสำเร็จ Git รูปแบบแตกแขนง" ถ้าคุณดูที่รุ่นนี้มันแม่นยำมาก: มันบอกว่าควรจะใช้รหัสใดที่เสถียรและมีการพัฒนาคุณสมบัติที่ไม่เสถียร นอกจากนี้ยังกล่าวถึงวิธีการและเมื่อถึงสาขาปรับปรุงและรวมกลับ คุณรู้ว่าแต่ละสาขานั้นมีไว้เพื่ออะไรและเกี่ยวข้องกับพวกเขาอย่างไร เราใช้รูปแบบของสิ่งที่นำเสนอโดย Vincent และรูปแบบของเราถูกกำหนดไว้ในวิกิของเรา

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

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

คุณสามารถเริ่มต้นด้วยสาขา "ที่ใหญ่ที่สุด" หรือสำคัญกว่า เช่น: "จากนี้เป็นต้นไปอาจารย์จะต้องอยู่ในสถานะที่จะนำไปใช้งานใน prod และสาขา dev จะต้องรวบรวมเสมอ" (หรือกฎของคุณ) จากนั้นบังคับใช้เวอร์ชัน (รีลีส) สาขา หลังจากนั้นบังคับใช้สาขาคุณลักษณะ หลังจากนั้นกำหนดให้โค้ดค้างในสาขาเวอร์ชันหากเหมาะสม

DevOps นั้นเกี่ยวกับการสื่อสารการเปิดกว้างและประสิทธิภาพ แนวคิดเหล่านี้จะต้องถูกเก็บไว้ในใจและสื่อสารตลอดกระบวนการ

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

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

จริง ๆ แล้วมันง่ายมากที่จะแปลงที่เก็บหลายไฮดราเป็นสาขาเดียว

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

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

คุณสามารถทำตามโครงร่างอย่างง่ายนี้เพื่อเริ่มต้น:

1. สร้างสำเนาของสาขาหลัก / ลำต้นของคุณและเรียกมัน temp_master
2. ค้นหาสาขาที่มีความแตกต่างที่ยิ่งใหญ่ที่สุดจากต้นแบบ / ลำตัว
3. ตรวจสอบว่าจำเป็นต้องเก็บรักษาจัดเก็บถาวรหรือลบสาขาหรือไม่
   1. หากจำเป็นต้องเก็บรักษาไว้ให้ทำตามขั้นตอนที่ 4
   2. หากจำเป็นต้องลบหรือเก็บถาวรให้ลบและเก็บถาวรจากนั้นกลับสู่ขั้นตอนที่ 2
4. ทำซ้ำขั้นตอนที่ 2 เพื่อค้นหาสาขาถัดไปด้วยความแตกต่างน้อยที่สุด
5. รวมสองสาขาที่พบในขั้นตอนที่ 2 และขั้นตอนที่ 3 เพื่อแก้ไขข้อขัดแย้งทั้งหมด
6. รวมสองสาขานี้เข้ากับtemp_masterสาขาของคุณ
7. ทดสอบรหัสในรหัส temp_master เพื่อดูว่ามันรวบรวมและสร้างและเรียกใช้การทดสอบอัตโนมัติอื่น ๆ ที่คุณมีสติ
   1. หากการทดสอบใดล้มเหลวให้ย้อนกลับไปค้นหาสาเหตุและแก้ไขและทำซ้ำกระบวนการ
   2. หากการทดสอบยังคงล้มเหลวให้เลือกสองสาขาที่แตกต่างกันเพื่อทำงาน
8. ทำซ้ำขั้นตอน 2-7 จนกว่าคุณจะมีเพียงสองสาขาหลักของคุณ / temp_masterลำตัวและ
9. สุดท้ายรวมtemp_masterเข้ากับต้นแบบ / ลำตัวแล้วใช้ชีวิตกับโมเดลสาขาเดียวใหม่ของคุณ

สำหรับองค์กรขนาดใหญ่ที่มีทั่วไป 4 สัปดาห์วิ่งรอบGit-Flowเป็นที่ต้องการวิธีการเพราะคุณจะได้รับประโยชน์ของสาขาสารคดีผลิตมหาบัณฑิตสาขาพร้อมอยู่เสมอ deployable นอกจากนี้สาขาต้นแบบจะถูกเก็บไว้ที่สะอาดจากกระทำที่ไม่พึงประสงค์โดยต่อไปนี้สองกระทำวงจร (จากคุณลักษณะDevelopและDevelopสาขา อาจารย์)

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