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


9

ฉันรู้มากของร้านค้าซอฟแวร์ให้ไบนารีภายใต้การควบคุมแหล่งที่มา อย่างไรก็ตามร้านค้าของเราได้เก็บเฟรมเวิร์กทั้งหมดไว้ในที่เก็บ: DirectX runtime, CUDA, nVidia Optix ไม่ว่าจะเป็นอะไรก็ตาม

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

ฉันไม่เคยเห็นรูปแบบการใช้งานเช่นนั้นมาก่อน คุณคิดว่าเป็นวิธีปฏิบัติที่ดีหรือไม่?

[แก้ไข:] ฉันไม่มีปัญหากับไบนารีบุคคลที่สามที่มีการควบคุมแหล่งที่มา คำถามหมายถึงกรอบเวลาทั้งหมดซึ่งประกอบด้วย 10+ ไบนารี ยกตัวอย่างเช่นใช้ Windows SDK (ซึ่งเราไม่ได้เก็บไว้ขอบคุณพระเจ้า แต่ฉันไม่เห็นความแตกต่างในหลักการ)


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

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

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

การสร้างภาพของเครื่องผู้พัฒนาจะเป็นการง่ายกว่าไหมหากการอัปเดตออกมา
Ramhound

@ แรมฮาวด์: นั่นเป็นทิศทางที่แน่นอนที่ฉันพยายามผลักดัน ฉันสงสัยว่ามีข้อเสียที่ฉันหายไป
Ofek Shilon

คำตอบ:


6

โดยทั่วไปไบนารีไม่เหมาะสำหรับระบบควบคุมเวอร์ชันเนื่องจาก:

  • ไม่ได้รับประโยชน์จากคุณสมบัติการควบคุมเวอร์ชัน (รวม, ต่างกัน)
  • พวกเขาเพิ่มขนาดของ repo ...
  • ... ซึ่งมีความสำคัญเนื่องจากคุณไม่ได้ลบเวอร์ชันออกจาก VCS อย่างง่ายดาย (VCS ถูกสร้างขึ้นเพื่อเก็บประวัติ) ตรงข้ามกับที่เก็บสิ่งประดิษฐ์เช่นNexusซึ่งเป็นไดเรกทอรีที่แชร์ง่าย ๆ (ทำความสะอาดง่าย: cd+ rm!)
  • ควรอ้างอิงใน VCS เป็นข้อความการประกาศ path + version: คุณสามารถเก็บประวัติที่เกี่ยวข้องด้วยวิธีนั้นบันทึกการเปลี่ยนแปลงของไบนารีเวอร์ชันเป็นการเปลี่ยนแปลงในไฟล์ข้อความนั้น (เช่น pom.xml หากคุณใช้ Nexus เช่น)

1
จุดสุดท้ายมีค่ามาก
Noufal Ibrahim

ขอบคุณ! คุณรู้จักคลังเก็บวัตถุที่คล้ายกันสำหรับโครงการ C ++ หรือไม่? ดียิ่งขึ้น - อาจเป็นหนึ่งในที่ทำงานร่วมกับ TFS?
Ofek Shilon

2
@OfekShilon: Nexus สามารถเก็บทฤษฎีสิ่งประดิษฐ์ใด ๆ แต่สำหรับการจัดเก็บและการจัดการการพึ่งพาสำหรับ NET / C ++ คุณยังมี NuGet: nuget.codeplex.com ตัวอย่างสำหรับ NET: lostechies.com/derekgreer/2011/09/20/... มันควรจะสนับสนุนโครงการ C ++ เช่นกัน: nuget.codeplex.com/discussions/280649
VonC

@OfekShilon คุณสามารถเชื่อมโยง TFS กับ NuGet (ตัวอย่าง: coolthingoftheday.blogspot.com/2011/08/… , hanselman.com/blog/ ...... ) ดูเพิ่มเติม TFSNuGetter: nugetter.codeplex.com
VonC

6

ฉันไม่เป็นไรกับรุ่นที่ควบคุมสินทรัพย์ไบนารี ฉันเทียบกับเวอร์ชันที่สร้างไฟล์ที่ควบคุมแล้ว

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

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


3

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

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

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


2

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

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


ฉันได้ชี้แจงคำถามเพื่อที่อยู่นี้
Ofek Shilon

1

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


1

มีเหตุผลที่ดีในการทำเช่นนี้คือคุณมีทุกสิ่งที่คุณต้องการในที่เดียวโดยไม่ต้องพึ่งพาภายนอก

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

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

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


2
หากคุณจัดเก็บห้องสมุดบุคคลที่สามของคุณในที่เก็บสิ่งประดิษฐ์เช่นเซิร์ฟเวอร์ Nexus หรือ NuGet ของคุณเองคุณไม่ต้องกลัวว่าเซิร์ฟเวอร์ "ผู้ขาย" จะหายไป ดังนั้นโดยเฉลี่ยแล้วเก็บไว้ในเครื่อง อย่าใช้ VCS พวกเขาไม่ได้ตั้งใจจะเก็บไฟล์ประเภทนั้นไว้
VonC

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

ตกลง. ฉันได้เห็นรูปแบบการใช้งานดังกล่าว AndI ต้องจัดการ repos ดังกล่าว (รวมศูนย์ VCS เช่น SVN หรือ ClearCase เป็นหลักไม่เคยเห็นการใช้งานสำหรับ DVCS เช่น Git) และนี่ก็เป็นระเบียบ การรีมาร์เก็ตติ้งไลบรารีผู้ขายคุณแทบจะไม่เก็บไบนารีเพียงครั้งเดียว คุณต้องจัดการกับแพทช์ จำนวนมาก การเพิ่มพื้นที่เก็บข้อมูลไม่ใช่เป้าหมายเดียว (ถ้าเป็นเช่นนั้น VCS อาจเป็นโซลูชันที่มีศักยภาพ) การจัดการการพึ่งพาคือ และสิ่งที่ Nexus หรือ NuGet มอบให้ (นอกเหนือจากการจัดการและล้างข้อมูล) ที่จัดเก็บได้ง่าย
VonC
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.