ไบนารีในการควบคุมแหล่งที่มา

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

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

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

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

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

ฉันได้พบวิธีการที่ง่ายที่สุดในการทำเช่นนี้คือการสร้างอิมเมจ ZIP หรือ ISO ของซีดีการติดตั้งและตรวจสอบสิ่งนี้ความคิดเห็นการเช็คอินจำเป็นต้องเป็นหมายเลขผู้ผลิตเฉพาะของ toolchain หาก gcc หรือคล้ายกันให้รวมทุกสิ่งที่คุณใช้เป็น ZIP ขนาดใหญ่และทำเช่นเดียวกัน

กรณีที่รุนแรงที่สุดที่ฉันเคยทำคือ Windows XP Embedded ที่ "toolchain" เป็น Windows XP VM ซึ่งรวมอยู่ (หลังจากนั้น) SQL Server และสแต็กของไฟล์การตั้งค่าพร้อมกับไฟล์ patch เป็นร้อย ๆ การติดตั้งล็อตล็อตและทำให้ทันสมัยใช้เวลาประมาณ 2-3 วัน การรักษาไว้สำหรับลูกหลานหมายถึงการตรวจสอบ ENTIRE VM เข้าสู่การควบคุมเวอร์ชัน เมื่อดูว่าดิสก์เสมือนถูกสร้างขึ้นจากอิมเมจประมาณ 6 x 2GB มันไปได้ค่อนข้างดี ฟังดูดีกว่า แต่มันทำให้ชีวิตง่ายขึ้นมากสำหรับคนที่ตามฉันมาและต้องใช้มัน - 5 ปีต่อมา

สรุป: การควบคุมเวอร์ชันเป็นเครื่องมือ ใช้มันให้มีประสิทธิภาพอย่าไปยุ่งเกี่ยวกับสิ่งต่าง ๆ เช่นความหมายของคำและอย่าเรียกมันว่า "แหล่งควบคุม" เพราะมันใหญ่กว่านั้น

Neal Ford โต้แย้งในThe Productive Programmerที่คุณควรเก็บไบนารีไว้ในการควบคุมแหล่งที่มา:

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

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

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

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

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

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

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

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

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

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

VCS ของฉันมีการตรวจสอบไบนารีมากมาย แต่แต่ละรายการเป็นหน่วยการปลดปล่อยจากผลิตภัณฑ์บางตัวที่ฉันไม่ได้เขียนและไม่ได้ทำการบำรุงรักษา นี่อาจเป็นสิ่งที่เหมือนกับ GNU ccRTP ซึ่งวางจำหน่ายในรูปแบบ tarball ที่ถูกบีบอัด tarball นั้นคือแหล่งที่มาของฉันและมันถูกตรวจสอบพร้อมกับโครงสร้างพื้นฐานอะไรก็ตามที่ฉันต้องการจะเปลี่ยนเป็นผลิตภัณฑ์สำเร็จรูป (Makefile และสเป็ค RPM ในกรณีของฉัน) ในขั้นตอนเดียวอัตโนมัติ เมื่อมี ccRTP เวอร์ชันใหม่ฉันปฏิบัติต่อ tarball ใหม่เป็นแหล่งที่เปลี่ยนแปลง: มันจะเป็นสำเนาที่ได้รับการตรวจสอบได้รับการสร้างทดสอบและส่งกลับไปยัง VCS ฉันทำสิ่งเดียวกันกับผลิตภัณฑ์เชิงพาณิชย์ที่ไม่ได้จัดส่งพร้อมกับแหล่งที่มา (คอมไพเลอร์ห้องสมุดและอื่น ๆ ) และทำงานในลักษณะเดียวกัน แทนการคลายแพ็กเกจกำหนดค่าคอมไพล์มันเป็นเพียงแค่แพ็คแพ็ค ซอฟต์แวร์ที่สร้างขึ้นทุกค่ำคืนไม่ได้ 'make และรับผลิตภัณฑ์สำเร็จรูป

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

สิ่งนี้ทำให้ฉันนึกถึงปัญหา "jars in repository" ที่บางครั้งที่ผ่านมา Java มี ผู้ที่สร้างแอพพลิเคชั่นจาวาถูกนำมาใช้เพื่อผลักดันการพึ่งพา (ไฟล์ไบนารี jar) ไปยังที่เก็บข้อมูล ทุกคนมีความสุขกับสิ่งนี้เพราะเราจะมีระบบการสร้าง "คลิกเดียว" และพื้นที่ดิสก์มีราคาถูกดังนั้นผู้ที่ใส่ใจ จากนั้น Maven ก็มาถึงและคุณสามารถกำจัด Cruft ไบนารีทั้งหมดนั้นได้และด้วยที่เก็บเฉพาะแคชในตัวเครื่องยังคงมีการสร้างสัญลักษณ์แสดงหัวข้อย่อย คุณยังมีระบบสร้าง "คลิกเดียว" แต่การควบคุมแหล่งที่มาไม่จำเป็นต้องสับเปลี่ยนไฟล์ไบนารีที่ไม่มีความหมาย

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

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

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

ดังนั้นใส่ไว้ในถ้ามันเป็นแหล่งที่มา ทำไม่ได้ถ้าไม่ใช่

เป้าหมายคือเพื่อให้สามารถรับรหัสล่าสุดและสร้างโดยไม่ต้องติดตั้ง / ตั้งค่าอะไร (เช่นเดียวกับการสร้าง "คลิกเดียว")

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

ดูโพสต์บล็อกนี้โดย Derek Greer ในเรื่อง

ฉันกำลังทำงานในโครงการที่มีสองขั้นตอนการสร้างที่แตกต่างกัน

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

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

กลยุทธ์ทั้งสองทำงานได้ดีและตอบสนองความต้องการ "การตรวจสอบจากการควบคุมซอร์สรวมทุกสิ่งที่คุณต้องการในการรวบรวมรหัส"

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

อย่างไรก็ตามคุณไม่จำเป็นต้องเก็บทุกอย่างไว้ในการควบคุมแหล่งที่มา

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

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

มันเป็นความโกลาหลอย่างมากในการเช็คอินไบนารี่ถึง SCM ในใจของฉัน ฉันทำงานโครงการที่ซับซ้อนมากซึ่งมีการพึ่งพาห้องสมุดส่วนที่สามเป็นจำนวนมาก หลักการที่เรานำมาใช้:

1. ซอร์สโค้ดทั้งหมดได้รับการจัดการด้วย SCM
2. การอ้างอิงทั้งหมดได้รับการจัดการด้วย Ivy ซึ่งมีการรวมคราสที่ยอดเยี่ยม

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

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

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

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

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