เป็นวิธีที่ดีที่สุดในการทำโครงการหลายองค์ประกอบ

10

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

มีใครพบวิธีที่ง่ายในการทำสิ่งนี้นอกเหนือจากรายการแยกจากกัน

versioning

— จอห์นสมิ ธ
แหล่งที่มา

1

ส่วนประกอบทั้งหมดถูกสร้างขึ้นพร้อมกันหรือไม่? พวกเขา "ปล่อย" ในเวลาเดียวกันหรือไม่?

— อดัมเลียร์

1

@ แอนนาเลียร์: ไม่ส่วนประกอบถูกสร้างและเผยแพร่ในเวลาต่างกัน

— John Smith

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

— Kwebble

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

— Alex Feinman

7

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

— Dave Nay
แหล่งที่มา

2

สิ่งที่ดูเหมือนในระบบควบคุมเวอร์ชันของคุณ? คุณ "ตรึง" โครงการย่อยทั้งหมดเมื่อคุณเปิดตัวรุ่นใหญ่หรือไม่?

— Robert Harvey

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

— Dave Nay

3

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

— Karl Bielefeldt
แหล่งที่มา

1

นี่คือสิ่งที่ฉันคิด แต่คุณจะจัดการสิ่งนี้ในสภาพแวดล้อม CI / CD ได้อย่างไร การจัดทำเอกสารนั้นดูเหมือนว่าเป็น PITA ที่แท้จริง

— Sinaesthetic

1

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

รูปแบบที่รู้จักกันดีสำหรับการกำหนดเวอร์ชันมาจากMicrosoft :

major version.minor version.build number.revision

ตัวอย่างเช่นคุณสามารถดูไฟล์ DLL ในแพลตฟอร์ม. NET เพื่อให้มีรุ่นเช่น 2.0.3600.1 หรืออะไรทำนองนั้น

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

— Saeed Neamati
แหล่งที่มา

ฉันไม่เห็นด้วยกับกลยุทธ์หมายเลขการสร้างของคุณ โดยทั่วไปหมายเลขบิลด์จะเปลี่ยนทุกครั้งที่คุณสร้างโครงการสำหรับส่วนประกอบที่กำหนดดังนั้นมันจะไม่ทำงาน

— Robert Harvey

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

— Saeed Neamati

การกำหนดเวอร์ชันประเภทนี้มีไว้เพื่อความเข้ากันได้และไม่ได้ตอบปัญหาจริงๆ

— Sinaesthetic

1

ระมัดระวังกับเวอร์ชันมันอาจฆ่าคุณ :-) อย่าพยายามทำสิ่งที่ซับซ้อนเกินไป

ฉันคิดว่าวิธีการต่อไปนี้อาจช่วยคุณได้:

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

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

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

— Victor Hurdugaci
แหล่งที่มา

1

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

หากคุณกำลังติดตามสิ่งที่คล้ายกับรูปแบบของ Microsoft:

major-version.minor-version.build-number.revision

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

หากคุณกำลังติดตามรูปแบบที่คล้ายกับสิ่งนี้:

Major-Version.Minor-Version.Build-Number

คุณจะต้องใช้หมายเลขบิลด์เพื่อติดตามเวอร์ชันคอมโพเนนต์แต่ละรายการ

— โรเบิร์ตฮาร์วีย์
แหล่งที่มา

0

หนังสือทั้งเล่มเขียนขึ้นเกี่ยวกับซอฟต์แวร์เวอร์ชัน

นี่คือวิธีการที่ฉันใช้

แต่ละส่วนมีรุ่นในรูปแบบ:

major.minor.developmental

แต่ละรายการเหล่านี้เป็นตัวเลขเริ่มต้นที่ 0

สำหรับการเปิดตัวอย่างเป็นทางการ (เช่นให้กับลูกค้า) ส่วนของการพัฒนาจะต้องเป็น 0 เสมอในเรื่องของนโยบาย

วิชาเอกนั้นเพิ่มขึ้นจากการตัดสินใจทางการตลาด

ส่วนย่อยจะเพิ่มขึ้นตามชุดคุณลักษณะที่ออกสู่ตลาด

ตัวอย่าง:

ฉันเริ่มพัฒนาส่วนประกอบใหม่ดังนั้นหมายเลขเวอร์ชันของฉันจะเป็น 0.0.1 เมื่อฉันปล่อยโต๊ะของฉันให้เพื่อนร่วมงานของฉันตัวอย่างเช่นสำหรับการทดสอบภายในจำนวนการพัฒนาเพิ่มขึ้นเป็น 0.0.2, 0.0.3 และอื่น ๆ
ฉันปล่อยสิ่งใหม่นี้สู่ตลาดในฐานะ 1.0.0 ซึ่งการเปลี่ยนแปลงที่อนุญาตเพียงอย่างเดียวจากจุดสิ้นสุดของการพัฒนาที่จะปล่อยคือการเปลี่ยนหมายเลขเวอร์ชัน (เช่น 0.0.43 -> 1.0.0)
คุณสมบัติใหม่บางอย่างจะถูกเพิ่ม ฉันเริ่มทำงานบนพื้นฐาน 1.0.0 เพิ่มคุณสมบัติเหล่านี้ดังนั้นรุ่นที่ฉันปล่อยให้เพื่อนร่วมงานของฉันสำหรับการทดสอบคือ 1.0.1, 1.0.2 และอื่น ๆ
คุณสมบัติต่อไปจะออกสู่ตลาดเป็น 1.1.0
การตลาดตัดสินใจว่าสิ่งที่ยิ่งใหญ่ต่อไปจะใหญ่มากดังนั้นมันจะออกมาเป็น 2.0.0 ฉันเริ่มทำงานกับ 1.1.1 ไปจนถึง 1.1.x แล้วปล่อยเป็น 2.0.0

และวัฏจักรนั้นซ้ำ

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

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

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

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

— quickly_now
แหล่งที่มา

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

— Robert Harvey

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

— quick_now

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

— quick_now

0

สรุป

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

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

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

ตัวอย่างจากประสบการณ์ส่วนตัว

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

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

Application name     (6a72e7c61f54)
    Library1         (b672a13a41e1)
        Library2     (9cc35769b23a)
    Library2         (9cc35769b23a)
    Library3         (4e9f56a0186a+)
        Library2     (9cc35769b23a)
    Library4         (2e3b08c4ac76)
        Library1     (b672a13a41e1)
            Library2 (9cc35769b23a)

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

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

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

หมายเหตุ: ระบบนี้จะทำงานได้จริง ๆ ถ้าคุณใช้ระบบควบคุมการแก้ไขซึ่งรับประกันแฮชที่กำหนดให้ส่งผลให้ไฟล์ชุดเดียวกันในไดเรกทอรีการทำงานของคุณ (เช่น git และ mercurial) หากไดเรกทอรีการทำงานที่กำหนดสามารถมีส่วนผสมของไฟล์ และไดเรกทอรีจากการแก้ไขหลาย ๆ ครั้ง (เช่น svn) การเดิมพันทั้งหมดจะปิดเกี่ยวกับสถานะของไดเรกทอรีการทำงานและวิธีการนี้จะไม่ทำงานเลย

— มาร์คบูธ
แหล่งที่มา