กลยุทธ์การผสานการพัฒนา 1 ปีใน Visual Studio

ฉันมีลูกค้าที่ยืนยันว่าเราแยกการพัฒนาใหม่ออกจากสาขาหลักตลอดทั้งปี 2559 พวกเขามีทีมอื่นอีก 3-4 ทีมที่ทำงานในแอปพลิเคชั่นในความสามารถที่หลากหลาย มีการเปลี่ยนแปลงขนาดใหญ่จำนวนมาก (การสลับวิธีการฉีดการพึ่งพาการทำความสะอาดโค้ดด้วย ReSharper ฯลฯ ) ตอนนี้ฉันตกหลุมรักที่จะรวมหลักในสาขาการพัฒนาใหม่ของเราเพื่อเตรียมที่จะผลักดันการเปลี่ยนแปลงของเราขึ้นโซ่

เมื่อดึงจดหมายเวียนครั้งแรกของฉัน TFS รายงานไฟล์ ~ 6500 ด้วยการแก้ไขข้อขัดแย้ง บางส่วนจะง่าย แต่บางตัวก็ยากกว่า (โดยเฉพาะบางตัวของจาวาสคริปต์ตัวควบคุม api และบริการที่สนับสนุนตัวควบคุมเหล่านี้)

มีวิธีที่ฉันสามารถทำได้ซึ่งจะทำให้เรื่องนี้ง่ายขึ้นสำหรับฉันหรือไม่

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

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

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

อย่างไรก็ตามวิธีที่ดีที่สุดคือ IMHO พยายามทำซ้ำสิ่งที่ควรเกิดขึ้นในมือแรก:

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

สิ่งนี้อาจใช้งานได้เมื่อทีมปฏิบัติตามกฎคลาสสิคของการควบคุมเวอร์ชันอย่างเคร่งครัด ("ยอมรับสถานะที่คอมไพล์แล้วทดสอบ" และ "เช็คอินเร็วและบ่อยครั้ง")

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

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

ฉันควรเพิ่มว่าคุณสามารถลองสิ่งนี้ได้เช่นกันด้วยการสลับข้าง - รวมการเปลี่ยนแปลงใหม่จากสาขาของคุณในส่วนเล็ก ๆ ไปยังบรรทัดหลัก สิ่งนี้อาจจะง่ายกว่านี้เมื่ออยู่บน dev สาขาของคุณมีการเปลี่ยนแปลงน้อยกว่าบน trunk มากหรือการเปลี่ยนแปลงส่วนใหญ่เกิดขึ้นในไฟล์ต้นฉบับใหม่ซึ่งปัจจุบันไม่ได้เป็นส่วนหนึ่งของ trunk เราสามารถเห็นสิ่งนี้ว่า "การย้าย" คุณสมบัติจากผลิตภัณฑ์ A (สาขา dev) ไปยังผลิตภัณฑ์ B ที่แตกต่างกันบ้าง (สถานะปัจจุบันของลำตัว) แต่ถ้าส่วนใหญ่ของ refactorings cross-cutting เสร็จแล้วในบรรทัดหลักและพวกเขาส่งผลกระทบต่อรหัสใหม่ของคุณ (การชนกันของการรวม 6500 ดูเหมือนจะเป็นหลักฐานบางอย่างสำหรับเรื่องนี้) มันอาจง่ายกว่าที่ฉันอธิบายไว้ก่อน

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

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

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

กุญแจสำคัญคือการไปต่อ

แก้ไข:

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

ขอบคุณความคิดเห็นจาก 'Jack Aidley' และ '17 of 26 '

ไม่กี่ปีก่อนเรามีลูกค้าที่มีความต้องการแยกสาขากัน ดังนั้นเราจึงทำ

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

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

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

มันจะไม่สนุก แต่ความเจ็บปวดนั้นขึ้นอยู่กับลักษณะของการเปลี่ยนแปลงและความโดดเดี่ยวของมัน

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

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

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

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