ในคอมไพล์วิธีการกำหนดเวอร์ชันสำหรับไลบรารีโหลทั้งหมดนั้นทำงานพร้อมกัน

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

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

ปัญหาหลายอย่างที่เราต้องจัดการในโครงการต้องการให้เราทำการเปลี่ยนแปลงในหลาย ๆ ไลบรารีและรหัสเฉพาะของโครงการ สิ่งเหล่านี้มักจะรวมถึงการเปลี่ยนแปลงอินเทอร์เฟซของไลบรารีซึ่งบางอย่างไม่เข้ากัน (ถ้าคุณคิดว่ามันฟังดูแปลก ๆ : เราเชื่อมต่อกับฮาร์ดแวร์และซ่อนฮาร์ดแวร์ที่เฉพาะเจาะจงไว้ข้างหลังอินเตอร์เฟสทั่วไปเกือบทุกครั้งที่เรารวมฮาร์ดแวร์ของผู้ขายรายอื่นที่เราพบในกรณีที่อินเทอร์เฟซปัจจุบันของเราไม่ได้คาดหวัง ตัวอย่างเช่นสมมติว่าโครงการที่P1ใช้ห้องสมุดL1, และL2 ยังใช้และ, และใช้เช่นกัน กราฟการพึ่งพามีลักษณะดังนี้:L3L1L2L3L2L3

   <-------L1<--+
P1 <----+  ^    |
   <-+  |  |    |
     |  +--L2   |
     |     ^    |
     |     |    |
     +-----L3---+

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

1. ใช้อินเทอร์เฟซใหม่ใน L3
2. ทำการดึงL3และรอการตรวจสอบ
3. ผสานการเปลี่ยนแปลง
4. สร้างรุ่นใหม่ของ L3
5. เริ่มทำงานกับคุณสมบัติP1โดยอ้างอิงจากรีL3ลีสใหม่แล้วนำฟีเจอร์นั้นไปใช้กับฟีเจอร์P1ของสาขา
6. ทำให้คำขอดึงได้รับการตรวจสอบและผสาน

(ฉันเพิ่งสังเกตุว่าฉันลืมที่จะเปลี่ยนL1และL2เปิดตัวใหม่และฉันไม่รู้ด้วยซ้ำว่าจะติดตั้งที่ใดเพราะจะต้องทำควบคู่ไปกับP1... )

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

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

ชนิดของการวางที่ชัดเจนที่นี่ แต่อาจจะพูดถึงมัน

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

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

มีข้อดี / ข้อเสียที่แข็งแกร่งในการนี้

ข้อดี:

• Tracability: สาขาแสดงทุกสิ่งที่เปลี่ยนแปลงในทุกโครงการ / lib ที่เกี่ยวข้องกับคุณสมบัติ / ข้อผิดพลาดนี้
• Bundling: เพียงแค่เลือกแท็กและคุณจะได้รับแหล่งข้อมูลทั้งหมดที่ถูกต้อง

ข้อเสีย:

• การผสาน: ... บางครั้งมันก็ยากด้วยโครงการเดียว เมื่อทีมต่าง ๆ ที่ทำงานในสาขาที่ใช้ร่วมกันต้องเตรียมพร้อมรับผลกระทบ
• อันตราย "โอ๊ะ" ปัจจัยถ้า messes พนักงานหนึ่งขึ้นพื้นที่เก็บข้อมูลโดยการทำผิดพลาดบางอย่างก็อาจจะส่งผลกระทบต่อทุกโครงการและทีมงาน

ขึ้นอยู่กับคุณที่จะรู้ว่าราคาคุ้มค่าหรือไม่

แก้ไข:

มันจะทำงานเช่นนี้:

• ต้องใช้คุณสมบัติ X
• สร้างสาขา feature_x
• นักพัฒนาทั้งหมดเกี่ยวข้องกับการทำงานในสาขานี้และทำงานเป็นคู่ขนานกับมันอาจอยู่ในไดเรกทอรีเฉพาะที่เกี่ยวข้องกับโครงการ / lib ของพวกเขา
• เมื่อเสร็จแล้วให้ตรวจสอบทดสอบบรรจุภัณฑ์อะไรก็ได้
• รวมมันกลับเข้าที่ในหลัก ... และนี่อาจเป็นส่วนที่ยากลำบากตั้งแต่ในระหว่างนี้feature_yและfeature_zอาจถูกเพิ่มเข้ามาด้วย มันกลายเป็น "การรวมข้ามทีม" นี่คือเหตุผลที่มันเป็นข้อเสียเปรียบอย่างรุนแรง

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

วิธีการแก้ปัญหาที่คุณกำลังมองหาคือเครื่องมือการจัดการการพึ่งพาในการประสานงานกับ submodules git

เครื่องมือเช่น:

• Maven
• มด
• นักแต่งเพลง

คุณสามารถใช้เครื่องมือเหล่านั้นเพื่อกำหนดการพึ่งพาของโครงการ

คุณสามารถกำหนดให้ submodule เป็นเวอร์ชั่นอย่างน้อย> 2.xxหรือแสดงช่วงของรุ่นที่เข้ากันได้= 2.2. *หรือน้อยกว่าเวอร์ชันที่เฉพาะเจาะจง<2.2.3

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

submodules

คุณควรจะลองgit submodulesตามที่แนะนำในความคิดเห็นเดียว

เมื่อโครงการP1หมายถึงสาม submodules L1, L2และL3ก็จริงเก็บการอ้างอิงถึงการกระทำโดยเฉพาะอย่างยิ่งในทั้งสามเก็บ: ผู้ที่มีการทำงานรุ่นของแต่ละห้องสมุดสำหรับโครงการที่

ดังนั้นหลายโครงการสามารถทำงานกับหลาย submodules: P1อาจหมายถึงไลบรารีเวอร์ชันเก่าL1ในขณะที่โครงการP2ใช้เวอร์ชันใหม่

เกิดอะไรขึ้นเมื่อคุณส่งรุ่นใหม่L3?

• ใช้อินเทอร์เฟซใหม่ใน L3
• ส่งทดสอบดึงคำขอตรวจทานรวม ... (คุณไม่สามารถหลีกเลี่ยงได้)
• ตรวจสอบให้แน่ใจL2ทำงานร่วมกับL3กระทำ ...
• ตรวจสอบให้แน่ใจว่าL1ทำงานกับใหม่L2...
• ตรวจสอบให้แน่ใจว่าP1ทำงานกับเวอร์ชันใหม่ของไลบรารีทั้งหมด:
  • ภายในP1's สำเนาการทำงานของท้องถิ่นL1, L2และL3, fetche การเปลี่ยนแปลงที่คุณอยู่ในความสนใจ
  • กระทำการเปลี่ยนแปลงgit add L1 L2 L3เพื่อคอมมิชชันการอ้างอิงใหม่ไปยังโมดูล
  • ดึงคำขอP1ทดสอบตรวจสอบดึงคำขอผสาน ...

ระเบียบวิธี

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

ใช่มันต้องมีการตรวจสอบอิสระเพราะคุณเปลี่ยน:

• ห้องสมุด
• ห้องสมุดที่ขึ้นอยู่กับมัน
• โครงการที่ขึ้นอยู่กับห้องสมุดหลายแห่ง

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

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

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

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

สิ่งที่ฉันเข้าใจคือสำหรับ P1 คุณต้องการเปลี่ยนอินเตอร์เฟส L3 แต่คุณต้องการอีก P2 และ P3 ซึ่งขึ้นอยู่กับอินเตอร์เฟส L3 เพื่อเปลี่ยนทันที นี่เป็นกรณีทั่วไปของความเข้ากันได้แบบย้อนหลัง มีบทความที่ดีเกี่ยวกับการรักษาความเข้ากันได้แบบย้อนหลังนี้

มีหลายวิธีที่คุณสามารถแก้ปัญหานี้:

• คุณต้องสร้างอินเทอร์เฟซใหม่ทุกครั้งที่สามารถขยายอินเทอร์เฟซเก่า

หรือ

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

หากฉันได้รับปัญหาของคุณถูกต้อง:

• ของคุณมี 4 โมดูลที่เกี่ยวข้องระหว่าง P1 และ L1 ถึง L3
• คุณต้องทำการเปลี่ยนแปลง P1 ซึ่งในที่สุดจะส่งผลต่อ L1 ถึง L3
• มันนับว่าเป็นความล้มเหลวของกระบวนการถ้าคุณต้องเปลี่ยนทั้ง 4 ด้วยกัน
• มันนับว่าเป็นความล้มเหลวของกระบวนการถ้าคุณต้องเปลี่ยนพวกเขาทั้งหมด 1 โดย 1
• มันนับว่าเป็นความล้มเหลวของกระบวนการหากคุณต้องระบุชิ้นล่วงหน้าที่ต้องทำการเปลี่ยนแปลงล่วงหน้า

ดังนั้นเป้าหมายคือคุณสามารถทำ P1 และ L1 ได้ในครั้งเดียวและอีกหนึ่งเดือนต่อมาก็ทำ L2 และ L3 อีกครั้ง

ในโลกของ Java นี่เป็นเรื่องเล็กน้อยและอาจเป็นวิธีเริ่มต้นในการทำงาน:

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

ดังนั้นคุณสามารถมีรหัสบนโลคัลดิสก์ของคุณสำหรับ L3 ที่จะไม่รวบรวมหากมันถูกรวบรวมเทียบกับสำเนาของ P1 ในไดเรกทอรีอื่นบนดิสก์ของคุณ โชคดีที่มันไม่ได้ทำเช่นนั้น Java สามารถทำสิ่งนี้ได้โดยตรงเนื่องจากการรวบรวม / เชื่อมโยงนิทานกับไฟล์ jar ที่คอมไพล์ไม่ใช่ซอร์สโค้ด

ฉันไม่ทราบวิธีแก้ปัญหาที่ใช้กันอย่างแพร่หลายในปัญหานี้สำหรับโลก C / C ++ และฉันคิดว่าคุณไม่ต้องการเปลี่ยนภาษา แต่บางสิ่งอาจถูกแฮ็กอย่างง่ายดายพร้อมกับสร้างไฟล์ที่ทำสิ่งที่เทียบเท่า:

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

คุณสามารถใช้การสนับสนุนC / C ++ ใน mavenแม้ว่านักพัฒนา C ส่วนใหญ่จะมองคุณแปลก ๆ ถ้าคุณทำ ...

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

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