ข้อเสนอแนะรูปแบบการแยกสาขาสำหรับโครงการเดียวกันลูกค้าหลายราย

เรามีโครงการขนาดใหญ่มากซึ่งรวมถึงแอปพลิเคชั่นหลายตัวที่ทำหน้าที่เป็นฐานสำหรับลูกค้าที่แตกต่างกัน

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

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

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

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

หมายเหตุ:เรากำลังพูดถึงโครงการที่มี 10 + M LOC

หมายเหตุ:เรากำลังใช้ Team Foundation System, Visual Studio 2008 และ C # (ส่วนใหญ่)

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

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

ชื่อของวิธีนี้คือซอฟท์แวสายผลิตภัณฑ์หรือบางครั้งสายผลิตภัณฑ์วิศวกรรม จากหน้าบรรทัดผลิตภัณฑ์ซอฟต์แวร์ของ CMU SEI :

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

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

แทนที่จะรักษาสาขาทั้งหมดเหล่านี้คุณจะต้องบำรุงรักษาระบบเดียวพร้อมกับชุดการกำหนดค่าเฉพาะลูกค้า

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

ลิงค์ที่มีประโยชน์เพิ่มเติม:

• Wikipedia: วิศวกรรมสายผลิตภัณฑ์
• กรณีศึกษาโดย CMU SEI
• สายผลิตภัณฑ์ซอฟต์แวร์ซึ่งเป็นเว็บไซต์ที่มีเนื้อหาเบื้องต้นมากมาย

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

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

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

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

ตัวอย่างเช่น

• รุ่น 1.0 ต้องใช้ Library A 1.0, Library B 2.0, Library C 5.6
• รีลีส 2.0 ต้องใช้ Library A 1.0, Library B 3.7, Library C 5.7
• รีลีส 3.0 ต้องใช้ไลบรารี A 1.2, Library B 3.7, Library C 5.8

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

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

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

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

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