คำถามด่วนเกี่ยวกับ TFS - พวกคุณเช็คอินโฟลเดอร์ bin / debug ใน TFS หรือไม่? (ถ้าเป็นเช่นนั้นทำไม?) เนื่องจากเนื้อหาของโฟลเดอร์เหล่านั้นถูกสร้างขึ้นแบบไดนามิกดีกว่าหรือไม่ที่จะปล่อยให้พวกเขาออกไปเพื่อที่โปรแกรมเมอร์จะไม่พบปัญหาแบบอ่านอย่างเดียว?
คำตอบ:
ตามกฎทั่วไปการควบคุมแหล่งที่มาจะใช้ดีที่สุดสำหรับแหล่งที่มาเท่านั้นและไฟล์ที่สร้างขึ้นไม่ได้เป็นแหล่งที่มา
มีข้อยกเว้นอยู่ บางครั้ง (โดยใช้ Visual Studio) คุณอาจต้องการเก็บไฟล์. pdb ไว้เพื่ออ่าน minidumps บางครั้งคุณไม่สามารถทำซ้ำ toolchain เพื่อให้คุณไม่สามารถสร้างไฟล์ที่สร้างขึ้นใหม่ได้อย่างถูกต้อง ในกรณีเหล่านี้คุณสนใจที่จะทำสิ่งนี้เป็นหลักสำหรับซอฟต์แวร์ที่วางจำหน่ายไม่ใช่สำหรับการเปลี่ยนแปลง VCS ทุกครั้งและในกรณีใด ๆ สิ่งเหล่านี้สามารถอยู่ในโฟลเดอร์เวอร์ชันได้อย่างง่ายดาย (โดยทั่วไปคือไฟล์ไบนารีและไม่มีการเปลี่ยนแปลงที่เข้าใจได้จากรุ่นหนึ่งไปยังอีกรุ่นหนึ่งและไม่ได้รับประโยชน์อะไรมากมายจากการอยู่ใน VCS)
คำตอบง่าย ๆ ? ไม่อย่าทำ! ฉันไม่สามารถคิดถึงเหตุผลมากมายไม่ได้ แต่ไม่มีเหตุผลว่าทำไมคุณถึงต้องการ
ครั้งเดียวที่ฉันสามารถคิดว่าคุณจะตรวจสอบใน dll คือถ้ามันมาจากห้องสมุดบุคคลที่สามที่คุณไม่คาดหวังว่านักพัฒนาทุกคนจะได้ติดตั้งเพื่อสร้าง แต่ถึงกระนั้นก็ยังไม่ได้อยู่ในโฟลเดอร์ถังขยะ
อย่างที่บอกไปแล้วว่าฉันทำงานที่ บริษัท แห่งหนึ่งซึ่งต้องการให้แต่ละแพ็คเกจการปรับใช้นั้นถูกควบคุมด้วยซอร์ส แต่นั่นก็เพื่อให้เราสามารถติดตามบิลด์ต่าง ๆ ที่เรามอบให้กับลูกค้าของเรา
เราไม่ได้เช็คอินโฟลเดอร์ bin ลงใน TFS ดังที่คุณอาจสังเกตเห็นถ้าคุณทำเช่นนั้นทุกครั้งที่นักพัฒนาสร้างโซลูชันพวกเขาจะตรวจสอบโฟลเดอร์ bin ไม่ดี. อย่างไรก็ตามมีไลบรารีที่โปรเจ็กต์ต้องการเพื่อคอมไพล์และรันและกฎของเราคือโปรเจ็กต์ใด ๆ ที่สามารถเปิดได้จากคอนโทรลแหล่งที่มาและควรคอมไพล์และรัน ดังนั้นสิ่งที่เราทำคือสร้างโฟลเดอร์ "BinRef" สำหรับ DLLs ใด ๆ ที่โครงการต้องมีการอ้างอิงและสร้างการอ้างอิงโครงการเพื่อคัดลอกในโฟลเดอร์ BinRef โฟลเดอร์ BinRef ถูกเช็คอินที่ TFS
ข้อดีอีกประการของวิธีนี้คือ BinRef อยู่ในระดับรากของโครงการเว็บเสมอ หากโครงการของฉันอาศัยอยู่C:\Projects\Marcie\SomeProjectCategory\ProjectAและฉันสร้างการอ้างอิงถึง DLL ที่อยู่ในC:\DLLsThatILikeการอ้างอิงจะจบลงด้วยการมองหาสิ่งที่ต้องการ
\..\..\..\NiceThing.dll
. คุณอาจเก็บไฟล์โครงการของคุณC:\ProjectAซึ่งหมายความว่าการอ้างอิงโครงการไปยัง NiceThing จะระเบิดในเครื่องของคุณ หวังว่าผู้คนจะไม่ทำการอ้างอิงด้วยวิธีนี้ แต่ฉันได้เห็นมันเกิดขึ้น
เราเช็คอินเนื้อหาของไดเรกทอรี bin ซึ่งเป็นส่วนหนึ่งของกระบวนการขอเปลี่ยนแปลงของเรา เพื่อหลีกเลี่ยงปัญหาแบบอ่านอย่างเดียวเราคัดลอกเนื้อหาไปยังโฟลเดอร์ที่แยกต่างหากและตรวจสอบจากที่นั่น นโยบายองค์กรของเรากำหนดให้ไบนารีทั้งหมดที่ไปสู่การผลิตได้รับการเช็คอินแยกต่างหากจากแหล่งที่มา มันไม่ใช่ทางออกที่ดีที่สุด แต่ใช้งานได้และให้ไฟล์ที่แน่นอนกับเราในการผลิต
ฉันลังเลที่จะตรวจสอบไฟล์ที่ไม่ใช่ข้อความใด ๆ ลงในการควบคุมแหล่งที่มา โดยเฉพาะอย่างยิ่งสิ่งที่ควรสร้างโดยนักพัฒนา ฉันยังต้องการเก็บไฟล์ไบนารีอื่น ๆ เช่นรูปภาพและ PDF ซิปขึ้นและเก็บไว้ที่อื่นสำหรับแต่ละแท็ก / รีลีส
ไม่ แต่เครื่องมือควบคุมโครงการในบ้านของเราทำโดยอัตโนมัติซึ่งทำให้เกิดความรำคาญกับฉัน
วิธีแก้ปัญหาของฉันคือทำเครื่องหมายไฟล์ทั้งหมดที่วางจำหน่ายและดีบักว่าสามารถเขียนได้และเมื่อ TFS บ่นฉันบอกให้ละเว้นไฟล์ดังนั้นฉันจึงไม่เคยมีปัญหากับบิลด์ที่ล้มเหลว
ฉันหลีกเลี่ยงการป้อนลงในการควบคุมแหล่งที่มา เป็นข้อมูลที่ซ้ำซ้อนไบนารีสามารถสร้างได้โดยซอร์สโค้ดในการแก้ไขนั้น นอกจากนี้ซอร์สโค้ดยังทันสมัยอยู่เสมอการ build อาจไม่สามารถคอมมิตได้
ฉันบันทึกบางไฟล์ไบนารีที่สร้างขึ้นเช่น. NET interops จากโครงการอื่น ดังนั้นถ้าฉันมีโครงการ A ซึ่งสร้างวัตถุ COM และจากนั้นคุณใช้วัตถุ COM นั้นในโครงการ B ที่เกี่ยวข้องอย่างหลวม ๆ ซึ่งใช้มันผ่าน. NET interop ฉันจะตรวจสอบใน interop ที่สร้างจากโครงการ A ไปยังโครงการ B มันคือ ไม่ใช่ความคิดที่ดี แต่ต้องไปที่ใดที่หนึ่งเพราะ AFAIK Visual Studio จะไม่สร้าง interop สำหรับคุณโดยอัตโนมัติในระหว่างการสร้าง
ในความคิดของฉันการไม่จัดเก็บไบนารีในการควบคุมแหล่งที่มาเป็นหนึ่งในข้อผิดพลาดที่พบบ่อยที่สุด พวกเขาควรจะเก็บ, รุ่น, พื้นฐาน / ติดป้ายพร้อมกับแหล่งที่มาและสร้างเครื่องมือ ชุดตัวเองด้วยการสร้างซอฟต์แวร์ที่ไม่สามารถติดตามได้ ...