คุณจะรักษาไบนารีที่เผยแพร่ภายใต้การควบคุมเวอร์ชันได้อย่างไร

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

สองตัวเลือก:

a) อย่า เพียงตรวจสอบให้แน่ใจว่าคุณมีงานสร้างที่สามารถกำหนดค่าได้ที่ทำซ้ำได้นั่นคือการสร้างการแก้ไขการควบคุมแหล่งเดียวกันด้วยการกำหนดค่าเดียวกันจะสร้างไบนารีที่แน่นอนเสมอ

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

ไม่ว่าจะด้วยวิธีใดไบนารีและเอาต์พุตการบิลด์อื่น ๆ ไม่ได้อยู่ในการควบคุมของแหล่งข้อมูลด้วยเหตุผลหลายประการ

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

ดูตัวอย่างที่เก็บ Maven เป็นที่เก็บเพื่อเก็บ / เผยแพร่ / เสนอการเสนอขายและไบนารีอื่น ๆ (เช่นเอกสารประกอบ)

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

ไบนารีเดลต้า SCM ส่วนใหญ่ค่อนข้างดีเราเคยใส่ dll ทรัพยากร 2Mb ลงใน SVN ของเราและมันจะเปลี่ยนเป็นไม่กี่กิโลไบต์ในแต่ละครั้ง

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

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

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

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

ทางออกที่ดีที่สุดคือการใช้ประโยชน์จากระบบ CI ของคุณสำหรับการสร้างที่สำคัญระดับองค์กรทั้งหมด

สิ่งนี้จะเชื่อมโยงไบนารีที่ถูกปล่อยอย่างเป็นระบบกับเนื้อหาที่เก็บโดยไม่ต้องเก็บไบนารีในที่เก็บจริง

ตัวอย่างเช่นหากคุณใช้ SVN ให้ใช้รูปแบบองค์กรที่มีสาขาเป็นหลัก พัฒนาทุกวันใน / trunk และสร้าง / แท็กสำหรับแต่ละรุ่นเมื่อพร้อม

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

• / สร้าง / ลำ / [รอบ] [วันที่] [build_id] /
• / สร้าง / แท็ก / release_0_1_3beta4 / [รอบ] [วันที่] [build_id] /

ระบบการสร้างจะต้องปฏิบัติต่อ/ builds / trunk /ไดเรกทอรีเช่นบัฟเฟอร์แบบวงกลมจัดเก็บการสร้าง n ครั้งล่าสุดการลบการสร้างเก่าตามที่ไป

ในขณะที่ไดเรกทอรี/ builds / tags /เป็นที่เก็บถาวร build builds เองถูกเก็บไว้ในไดเร็กทอรีที่มีชื่อที่สร้างขึ้นตามแบบแผนต่อไปนี้:

• [รอบ] [วันที่] [build_id]

โดยที่[rev]คือรหัสการแก้ไข SVN, [date]คือวันที่ในรูปแบบ YYYYMMDD และ[build_id]เป็นตัวนับที่ไม่ซ้ำกัน 3 หลักซึ่งเพิ่มขึ้นจากการสร้างครั้งแรกเป็นต้นไปทำให้แต่ละไดเรกทอรีการสร้างไม่ซ้ำกัน

กระบวนการรายละเอียดข้างต้นให้ประโยชน์ดังต่อไปนี้:

1. Build artifacts นั้นเชื่อมโยงกับแหล่งที่สร้างขึ้นอย่างเป็นระบบดังนั้นคุณสามารถค้นหาแหล่งที่มาของสิ่งประดิษฐ์ build ได้อย่างง่ายดาย (และในทางกลับกัน)

2. นี่เป็นพื้นฐานสำหรับการวางจำหน่ายอัตโนมัติเพิ่มเติม ตัวอย่างเช่นการสร้างเอกสารเผยแพร่อัตโนมัติ ฯลฯ ...