กลยุทธ์การแบ่งสาขาและการกำหนดเวอร์ชันสำหรับไลบรารีที่แบ่งใช้


12

ข้อความเหล่านี้ดูเหมือนว่าเกี่ยวข้อง แต่สมองของฉันเริ่มละลายพยายามคิดผ่าน: P

นายจ้างของฉันเพิ่งเริ่มใช้การควบคุมแหล่งที่มาส่วนใหญ่เป็นเพราะก่อนที่พวกเขาจะจ้างนักพัฒนามากขึ้น "ที่เก็บ" คือฮาร์ดไดรฟ์ของ dev ที่โดดเดี่ยวซึ่งทำงานจากที่บ้านเป็นหลัก ทั้งหมดของรหัส .NET เขาต้องการเขียนได้รับการตรวจสอบในว่อนและมีเป็นจำนวนมากของการทำซ้ำ (อ่าน: คัดลอกวาง) ฟังก์ชั่น ตอนนี้ระบบ SCM ของเราได้รับการเชิดชูข้อมูลสำรอง

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

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

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

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

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

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


ค่าใช้จ่ายคงที่คือจม
ทางเลือก

คำตอบ:


1

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

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

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

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


6

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

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

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


4

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

ประโยชน์บางอย่าง:

  1. การดีบักง่ายขึ้นของแต่ละโมดูล
  2. รอบบิลด์ที่เร็วขึ้น (ไม่มีการสร้างไลบรารีที่ไม่เปลี่ยนแปลง)
  3. เมื่อสิ่งที่ใช้งานมีโอกาสน้อยที่คุณจะทำลายมันโดยเปลี่ยนพื้นที่อื่นนอกโมดูลนั้น (ไม่ใช่ 100% แต่คุณลดโอกาส)
  4. ง่ายกว่าในการแยกงานที่มอบหมายออกหากไม่ใช่ระเบียบที่พึ่งพาซึ่งกันและกัน
  5. การกระจายที่เร็วกว่าของชิ้นเล็กลงเมื่อคุณแก้ไขหนึ่งไลบรารี (เหตุผลใหญ่ว่าทำไมคุณมีไฟล์. dll / .so)

ฉันมีคำถามหนึ่งข้อเกี่ยวกับส่วนนี้:

"ทางออกที่ดีที่สุดในใจของฉันคือการสร้างห้องสมุดแยกต่างหากโดยแต่ละโครงการขึ้นอยู่กับรุ่นที่เข้ากันได้ซึ่งเลือกโดยเจตนา"

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

ข้อเสียบางประการ:

  1. หากโครงการมีขนาดเล็กคุณเพียงแค่เพิ่มความซับซ้อนในที่ที่ไม่จำเป็น
  2. การแยกโมดูลจำนวนมากสามารถกลายเป็นปัญหาการบำรุงรักษาสำหรับโครงการขนาดใหญ่จริง ๆ ฉันไม่รู้จัก "ห้องนิรภัย" ดังนั้นฉันไม่แน่ใจว่าการดำเนินการแยกสาขาของพวกเขาดีหรือไม่ดี

มันคือรหัส C # ดังนั้นจึงเป็น "ไม่" ในการลิงก์แบบสแตติกในความหมายปกติ ห้องนิรภัยเป็นเหมือนการโค่นล้มก่อน 1.5: PI รอเพื่อให้กระหายสำหรับการติดตามผสานใน SVN คิดผมอยู่ในสวรรค์เมื่อมันมาถึงในที่สุด จากนั้นฉันก็พบ DVCS
shambulator

1

ตอนนี้ดูเหมือนว่าคุณมีหนึ่ง codebase ถูกสร้างขึ้นทั้งหมดในครั้งเดียวเป็นเป้าหมาย คุณอาจมีนักพัฒนาไม่เกินห้าคน ฉันไม่เห็นประโยชน์ของการแยกไลบรารีมากเกินไป คุณต้องการเปลี่ยนเวิร์กโฟลว์ของคุณจากรหัส -> รวบรวม -> เรียกใช้รหัส -> รวบรวม -> คัดลอก DLL -> รวบรวม -> เรียกใช้ ... ick

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

หากไม่มีโครงสร้างพื้นฐานฉันจะแยกโครงการเมื่อมีสิ่งใดสิ่งหนึ่งต่อไปนี้ที่เกี่ยวข้อง:

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

ฉันกังวลเกี่ยวกับการสร้างโครงสร้างพื้นฐานนั้นเมื่อคุณมีโครงการจำนวนมากและบางแห่งมีนักพัฒนาและนักออกแบบอิสระโดยเฉพาะ

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

เมื่อคุณมีเซิร์ฟเวอร์สำหรับสร้างแล้วการแยกออกจากไลบรารีจะเป็นเรื่องของการย้ายใน Vault เพิ่มเป้าหมายอื่นใน CC.NET และคัดลอก DLL ที่เป็นผลลัพธ์ลงในโฟลเดอร์ไลบรารีของโครงการหลักของคุณ ง่ายกว่าในด้าน SCM มากกว่าการพัฒนาแบบวันต่อวัน


1

Mercurial มีคุณสมบัติที่เรียกว่า subrepositories ฉันเพิ่งอ่านบล็อกนี้จากเตาเผาอธิบายว่าพวกเขาทำงานอย่างไร

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

บางทีห้องนิรภัยก็มีคุณสมบัติคล้ายกัน


1

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.