วิธีที่ดีที่สุดในการจัดการการกำหนดเวอร์ชันผลิตภัณฑ์และการแยกของโครงการระยะยาวคืออะไร

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

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

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

คุณต้องการโครงสร้าง (และชนิดใด) มากขึ้นอยู่กับสิ่งที่คุณต้องการจะทำ ค้นหาสิ่งที่คุณขาดไม่ได้สิ่งที่คุณต้องการและสิ่งที่คุณไม่สนใจ

ตัวอย่างชุดการตัดสินใจที่ดีอาจเป็น:

สิ่งที่เราขาดไม่ได้:

• สามารถสร้างการวางจำหน่ายที่ผ่านมาได้ตลอดเวลา
• สามารถรักษาผลิตภัณฑ์รุ่นใหญ่ที่รองรับได้หลายรายการได้ตลอดเวลา

สิ่งที่เราต้องการ:

• สามารถทำการพัฒนาฟีเจอร์สำคัญอย่างต่อเนื่อง (สำหรับการเปิดตัวครั้งสำคัญครั้งต่อไป) โดยไม่ต้องกังวลเกี่ยวกับการรวมสาขา
• สามารถทำการปรับปรุงการบำรุงรักษาเพื่อการเผยแพร่ที่ผ่านมา

สิ่งที่เราสามารถอยู่ได้โดยปราศจาก:

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

หากข้างต้นเป็นเป้าหมายของคุณคุณสามารถใช้กระบวนการเช่นนี้ได้:

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

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

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

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

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

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

ฉันไม่ทราบ แต่แน่นอนว่ามันจะมีอยู่ซึ่งเป็นส่วนเสริมของเครื่องมือ CM สำหรับ Git

คำถามนี้ดูเหมือนจะคล้ายกับคำถามอื่นที่ฉันตอบเมื่อเร็ว ๆ นี้

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

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

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