เป็นการดีหรือไม่ที่จะเก็บหมายเลขเวอร์ชันของซอฟต์แวร์ใน VCS?

เวอร์ชันผลิตภัณฑ์เช่นv1.0.0.100ไม่เพียงแสดงถึงการผลิตซอฟต์แวร์ที่ไม่ซ้ำใคร แต่ช่วยระบุชุดคุณลักษณะและขั้นตอนการแก้ไขด่วนสำหรับผลิตภัณฑ์ดังกล่าว ตอนนี้ฉันเห็นสองวิธีในการรักษาแพ็กเกจ / build / ไบนารีเวอร์ชันสุดท้ายของผลิตภัณฑ์:

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

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

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

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

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

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

— void.pointer
แหล่งที่มา

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

— 5gon12eder

@ 5gon12eder ความยากลำบากหรือความรู้สึกเกี่ยวกับการรวมตัวเองนั้นไม่เกี่ยวข้อง มันเป็นเพียงด้านลบของโซลูชันโดยรวม

— void.pointer

คำตอบ:

ส่วนตัวฉันเลือกตัวเลือก 3: เก็บข้อมูลการกำหนดเวอร์ชันไว้ในเมตาดาต้า VCS โดยเฉพาะแท็ก

Git ทำให้ง่ายในการทำเช่นนั้นเพราะมีคำสั่งgit describeซึ่งสามารถอธิบายการกระทำที่ไม่ซ้ำกันโดยใช้แท็ก นี่คือวิธีการทำงาน:

หากการคอมมิทปัจจุบันถูกแท็กเอาท์พุทชื่อของแท็ก
<tag>-<number of commits since the tag>-g<abbreviated commit hash>มิฉะนั้นเดินถอยหลังประวัติศาสตร์จนกว่าคุณจะพบแท็กและเอาท์พุทจากนั้นคำอธิบายในรูปแบบต่อไปนี้:
หากมีการเปลี่ยนแปลงข้อผูกมัดใน workingtree, -dirtyผนวก

ดังนั้นถ้าคุณกำลังทำปล่อยสร้างและได้กระทำการติดแท็กก็จะเอาท์พุท1.2.3 1.2.3หากคุณกำลังทำงานกับ 1.2.4 และคุณทำ 4 กระทำตั้งแต่ 1.2.3 1.2.3-4-gdeadbee-dirtyและมีการเปลี่ยนแปลงที่ปราศจากข้อผูกมัดในต้นไม้ก็จะเอาท์พุท

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

— Jörg W Mittag
แหล่งที่มา

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

— void.pointer

git describeยังทำงานร่วมกับสาขา: " --all - แทนการใช้เพียงแท็กข้อเขียนใช้โทษใด ๆ ที่พบในrefs/namespace ตัวเลือกนี้จะช่วยให้ตรงกับสาขาที่รู้จักกันใด ๆ ระยะไกลติดตามสาขาหรือที่มีน้ำหนักเบาแท็ก.." ไม่แน่ใจว่าวิธีนี้ใช้ได้กับ Bamboo อย่างไร (แน่นอนว่าจะต้องมีการตั้งชื่ออย่างระมัดระวังเช่นเดียวกับโหมดปกติที่มีแท็ก)

— Jörg W Mittag

ฉันรู้ว่าคนบางกลุ่มที่เผยแพร่อัตโนมัติโดยสมบูรณ์จาก Git สตริงรุ่นที่สร้างขึ้นโดยgit describeChangeLog ถูกสร้างขึ้นจากgit shortlog(จริง ๆ แล้วมาจากสคริปต์ที่แยกวิเคราะห์ผลลัพธ์ของgit log --pretty=tformat:<some custom format string>) และบันทึกประจำรุ่นที่สร้างขึ้นจากคำอธิบายแท็กและgit notesแนบมากับเหตุการณ์สำคัญที่สำคัญ

— Jörg W Mittag

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

— void.pointer

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

— Jörg W Mittag

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

เพื่ออำนวยความสะดวกใน. NET เราได้ทำ exe line ขนาดเล็ก cmd ที่มุ่งมั่นที่จะคอมไพล์ ด้วยเหตุการณ์ที่สร้างล่วงหน้าจะรับหมายเลขบิลด์ที่แท็กทีมในระหว่างการสร้าง เครื่องมือบรรทัด cmd นี้สร้างคลาสที่มีค่าคงที่หนึ่งที่มีหมายเลขบิลด์โดยอัตโนมัติ ส่วนที่เหลือของหมายเลขเวอร์ชั่น: major.minor.patch เป็นค่าคงที่ปกติในไฟล์อื่น ไฟล์ที่แบ่งใช้สองไฟล์เหล่านี้รวมอยู่ในทุกแอสเซมบลีในโซลูชันเป็นลิงก์ (alt + shift-drag)

วิธีการนี้มีประสิทธิภาพเพียงพอที่เราสามารถสร้างทีมงานและทดสอบรหัสของเรา กดเพื่อเป็นสีฟ้าและให้ kudu สร้างมันขึ้นมาอีกครั้ง แต่ด้วยหมายเลขการสร้าง teamcity เป็นรุ่นของ dll

— Esben Skov Pedersen
แหล่งที่มา