หมายเลขบิลด์ใน MAJOR.MINOR.BUILDNUMBER.REVISION คืออะไร

สิ่งที่ฉันคิดเกี่ยวกับ Build Numbers คือเมื่อใดก็ตามที่สร้างบิลด์ใหม่ทุกคืนบิลด์ใหม่จะถูกสร้างและกำหนดให้กับบิลด์นั้น ดังนั้นสำหรับแอปพลิเคชันเวอร์ชัน 7.0 ของฉันบิลด์บิลด์ต่อคืนจะเป็น 7.0.1, 7.0.2 เป็นต้น มันเป็นอย่างนั้นเหรอ? ถ้าเช่นนั้นการใช้ REVISION หลังจากหมายเลขบิลด์คืออะไร? หรือว่าส่วนการปรับปรุงจะเพิ่มขึ้นหลังจากการสร้างทุกคืน? ฉันสับสนเล็กน้อยที่นี่ ... เราจะอ้างถึงยามค่ำคืนสร้างแต่ละเป็นBUILD ?

รูปแบบที่กล่าวถึงที่นี่: AssemblyVersion - MSDN

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

ตัวอย่างเช่นการแก้ไขอาจถูกปล่อยไปยัง QA (การควบคุมคุณภาพ) และพวกเขากลับมาพร้อมกับปัญหาที่ต้องมีการเปลี่ยนแปลง ข้อผิดพลาดจะได้รับการแก้ไขและปล่อยกลับไปยัง QA ด้วยหมายเลข REVISION เดียวกัน แต่จะเพิ่ม BUILDNUMBER

ความสับสนทั้งหมดเกิดจากความหมายต่าง ๆที่ MS ใช้สำหรับ "Build number" และโดยเฉพาะ "Revision" เงื่อนไขหมายถึงสิ่งที่แตกต่าง

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

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

• กระทำหมายเลข 4711: อลิซเพิ่มคุณสมบัติ A
• CI สร้างบิลด์ 1.2.3.100
• ส่งหมายเลข 4712: คุณลักษณะที่แก้ไขของ Bob
• กระทำหมายเลข 4713: คุณลักษณะถาวรของอลิซ A ("โปรแกรมแก้ไขด่วน")
• CI สร้างการสร้าง 1.2.3.101

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

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

• ส่งหมายเลข 4711: อลิซได้เพิ่มคุณสมบัติ A ไปยังช่องเก็บของ
• คาร์ลสร้างงานสร้างสาขา 1.2.100
• CI สร้างการสร้าง 1.2.100.0
• ส่งหมายเลข 4712: คุณลักษณะที่แก้ไขของ Bob ในลำตัว / ตัวหลัก
• กระทำหมายเลข 4713: คุณลักษณะถาวรของอลิซ A ใน1.2.100สาขา
• CI สร้างบิลด์ 1.2.100.1

คำว่า REVISION อาจอ้างถึง

• การแก้ไขผลิตภัณฑ์ (เป็นวิธีที่คนส่วนใหญ่ใช้)
• การแก้ไขการสร้างรายวันเฉพาะ(นั่นคือสิ่งที่ MS ทำ)

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

ในกรณีของเราเครื่องมือ CI สร้างแท็กที่เก็บดังนั้นเราจึงมีข้อมูลที่จำเป็นพร้อมใช้เสมอเมื่อจำเป็น ด้วย SVN มันจะกลายเป็นเรื่องที่ง่ายขึ้นเพราะแท็กและกิ่งไม้ได้รับการใช้งานในลักษณะเดียวกัน - แท็กไม่มีอะไรมากไปกว่าสาขาที่อยู่ด้าน/tagsล่าง

ดูสิ่งนี้ด้วย

จากส่วนคำถามที่พบบ่อยที่กลยุทธ์การแยกสาขาของ TFS :

ฉันควรแก้ไขตั๋ว P1 (โปรแกรมแก้ไขด่วน) สาขาใด

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

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

การอ่านที่ดีอีกอย่างคือคู่มือการแยกสาขาของ TFS

Microsoft อธิบายถึงวัตถุประสงค์ของแต่ละองค์ประกอบของหมายเลขรุ่น. NET ในเอกสารประกอบ MSDN สำหรับVersionชั้นเรียน นี่คือส่วนที่เกี่ยวข้อง:

MAJOR.MINOR [.build [.revision]]

ส่วนประกอบที่ใช้โดยการประชุมดังต่อไปนี้:

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

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

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

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

http://msdn.microsoft.com/en-us/library/system.version.aspx

อย่างน้อยก็มีหลายสิ่งที่แตกต่างกันที่ฉันสามารถจินตนาการถึงการสร้างหมายเลขอ้างอิง:

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

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

อาจมีคนอื่นที่ฉันไม่รู้ แต่นี่เป็นเรื่องใหญ่ที่ฉันรู้เมื่อพูดถึงตัวเลขในโค้ดเบส

หมายเลขบิลด์มักเพิ่มขึ้นในทุกบิลด์ดังนั้นจึงไม่ซ้ำกัน

เพื่อความเรียบง่ายบางรีเซ็ตหมายเลขบิลด์เมื่อใดก็ตามที่หมายเลข MAJOR หรือ MINOR ถูกชน

เอ็นจินการรวมอย่างต่อเนื่องส่วนใหญ่อนุญาตให้สร้างหมายเลขการสร้างที่ไม่ซ้ำโดยอัตโนมัติ

การแก้ไขสามารถใช้สำหรับแพทช์ของบิลด์ ให้บอกว่า 2 ทีมทำงานกับผลิตภัณฑ์

ทีม 1 เป็นทีมพัฒนาที่สำคัญและสร้างบิลด์ยามค่ำคืนด้วยสกีมาเวอร์ชันต่อไปนี้ 1.0.X.0 โดยที่ X เพิ่มขึ้น ตอนนี้พวกเขาอยู่ที่การสร้าง 1.0.50.0 ทีม 2 กำลังทำการสร้างเป็นครั้งคราว สมมติว่าพวกเขารับงานสร้างเมื่อสัปดาห์ที่แล้วซึ่งเป็น 1.0.43.0 และเริ่มใช้งานได้ ทีม 1 เข้าสู่ 1.0.51.0 เมื่อทีม 2 พบปัญหาใน 1.0.43.0

ตอนนี้ทีม 1 จะรับบิลด์นั้น (43), แก้ไขปัญหาและมอบการสร้าง 1.0.43.1 ให้กับทีม 2 การแก้ไขอาจถูกแพร่กระจายในบิลด์หลักด้วยดังนั้นการเปลี่ยนแปลงจะปรากฏใน 1.0.52.0

หวังว่านี่จะชัดเจนและเป็นประโยชน์

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

ให้ฉันบอกว่าฉันเห็นและใช้มันอย่างไร ....

ProgramName รุ่น main.minor.build.revision

วิชาเอก: สำหรับฉันเป็นโครงการปัจจุบันที่ฉันทำงานอยู่ จำนวนจะไม่เปลี่ยนแปลงจนกว่าฉันจะเริ่มโครงการใหม่ที่มีชื่อโปรแกรมเดียวกัน ซึ่งหมายความว่าฉันจะเขียนโปรแกรมใหม่ที่มีเพศเดียวกัน (ตัวอย่างเช่น access v1 - access v-2 - access v-3 * ทั้งหมดที่เป็นโปรแกรมเดียวกัน แต่เขียนใหม่ทั้งหมด)

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

บิลด์: ฉันใช้เพื่อระบุการเปลี่ยนแปลงเล็กน้อยในเวอร์ชัน Major.minor ที่เผยแพร่แล้ว นี่อาจเป็นการเปลี่ยนแปลงในเค้าโครงโครงร่างสี ฯลฯ

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

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

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

ฉันเคยเห็นหมายเลขบิลด์เป็นหมายเลขสุดท้ายในรหัสเผยแพร่ ฉันไม่แน่ใจว่าคุณจะได้รับการแก้ไขหมายเลขบิลด์ได้อย่างไร ฉันคิดว่าถ้าคุณเปลี่ยนทรัพยากรที่ไม่ได้สร้างขึ้น (ไอคอน, สคริปต์ฐานข้อมูล, ฯลฯ ) บางที แต่โครงการส่วนใหญ่ที่ฉันเคยทำเมื่อเร็ว ๆ นี้มีทุกสิ่งที่อยู่ภายใต้การควบคุมเวอร์ชันเช่นกันดังนั้นกระบวนการสร้างจึงเลือกพวกเขาเมื่อ ทำให้การติดตั้ง / ปล่อย ฉันชอบหมายเลขบิลด์ที่ประทับเวลาแม้ว่าจะไม่เป็นอย่างที่ @David อธิบาย (ฉันชอบ major.minor.revision.HHMM) อย่างไรก็ตามที่ที่ฉันทำงานเราใช้หมายเลขต่อเนื่องที่บิลด์เซิร์ฟเวอร์ของเราสร้าง

เช่นเดียวกับ jkohlhepp เราใช้ส่วนที่สามของเวอร์ชันเพื่อแสดงหมายเลขการแก้ไขใน SubVersion และอันดับที่สี่เพื่อแสดงหมายเลขบิลด์จากเซิร์ฟเวอร์รวมอย่างต่อเนื่องของเรา (Jenkins สำหรับเรา) สิ่งนี้ทำให้เราได้รับประโยชน์มากมาย - การมีหมายเลขรุ่นที่กำหนดโดยเซิร์ฟเวอร์ CI ของเราจะลบขั้นตอนแบบแมนนวลที่อาจพลาดไปโดยไม่ได้ตั้งใจ มันง่ายที่จะตรวจสอบว่าผู้พัฒนาไม่ได้ทำการปล่อยหน้าด้านบนพีซีที่กำลังพัฒนา (ซึ่งจะส่งผลให้ตัวเลขเหล่านี้เป็นศูนย์); และช่วยให้เราสามารถผูกซอฟต์แวร์ใด ๆ กลับไปที่โค้ดที่สร้างจากและงาน CI ที่สร้างขึ้นเพียงแค่ดูหมายเลขรุ่น - ซึ่งบางครั้งเราพบว่ามีประโยชน์มาก

มันคือสิ่งที่คุณต้องการให้เป็น ฉันมักจะใช้ year.month.day.hhmm สำหรับ major.minor.build.revision ของฉัน ถ้าฉันผลิตมากกว่าหนึ่งนาทีมีอะไรผิดปกติ คุณสามารถใช้การเพิ่มขึ้นแบบง่าย ๆ หรือฉันได้เห็นเครื่องกำเนิดไฟฟ้าที่ซับซ้อนสำหรับพวกเขา ทำในสิ่งที่คุณอยากให้มันเป็น สิ่งที่พวกเขาต้องทำคือทำให้คุณได้รับไปยังแหล่งที่ใช้สร้างผลลัพธ์นั้นดังนั้นอะไรก็ตามที่คุณสามารถทำได้

ตัวเลขสองหลักสุดท้ายคือหมายเลขบิลด์ทั้งหมด

1.01.2.1234

หมายเลขบิลด์คือ 2.1234 แต่คนส่วนใหญ่จะใช้เพียง 1234 เนื่องจากส่วนที่ 2 ไม่เปลี่ยนบ่อย

ทีมของเราใช้หมายเลขที่สาม (การแก้ไข) เป็นหมายเลขการแก้ไขจากพื้นที่เก็บข้อมูลการโค่นล้ม เราใช้หมายเลขที่สี่ (บิลด์) เป็นหมายเลขบิลด์จากเซิร์ฟเวอร์รวมอย่างต่อเนื่องของ TeamCity ซึ่งสร้างบิลด์ TeamCity สร้างไฟล์ AssemblyInfo ใหม่พร้อม #s ด้านขวาในระหว่างกระบวนการสร้าง