ประสบการณ์ที่ยากลำบากได้สอนฉันว่าเกือบทุกอย่างอยู่ในการควบคุมของแหล่งที่มา (ความเห็นของฉันที่นี่มีการเปลี่ยนแปลงในทศวรรษและครึ่งหนึ่งสำหรับการพัฒนาระบบฝังตัว / โทรคมนาคมบนฮาร์ดแวร์ที่เป็นกรรมสิทธิ์ที่มีกรรมสิทธิ์และบางครั้งก็หายากเครื่องมือ)
คำตอบบางส่วนของที่นี่บอกว่า "อย่าใส่ไบนารีในแหล่งควบคุม" มันผิด เมื่อคุณกำลังทำงานในผลิตภัณฑ์ที่มีจำนวนมากรหัสของบุคคลที่สามและจำนวนมากของห้องสมุดไบนารีจากผู้ขายที่คุณตรวจสอบในห้องสมุดไบนารี เพราะถ้าคุณทำไม่ได้ในบางจุดคุณจะต้องอัพเกรดและคุณจะเจอปัญหา: การหยุดพักเนื่องจากเครื่องสร้างไม่มีรุ่นล่าสุด มีคนให้ซีดีเก่าแก่คนใหม่ในการติดตั้ง wiki ของโครงการมีคำแนะนำที่เก่าแก่เกี่ยวกับเวอร์ชันที่จะติดตั้ง หากคุณต้องทำงานอย่างใกล้ชิดกับผู้ขายเพื่อแก้ไขปัญหาเฉพาะและพวกเขาส่งห้องสมุดห้าชุดในหนึ่งสัปดาห์คุณต้องสามารถติดตามชุดของไบนารีที่แสดงพฤติกรรมใด ระบบควบคุมแหล่งที่มาเป็นเครื่องมือที่ช่วยแก้ปัญหานั้นได้อย่างแน่นอน
คำตอบบางส่วนของที่นี่บอกว่า "อย่าใส่เครื่องมือในการควบคุมแหล่งที่มา" ฉันจะไม่พูดมันผิด แต่มันเป็นเรื่องที่ดีที่สุดที่จะนำ toolchain ในการควบคุมแหล่ง จนกว่าคุณจะมีการบริหารจัดการการกำหนดค่าหินแข็ง (CM) ระบบสำหรับมัน พิจารณาปัญหาการอัปเกรดอีกครั้งตามที่กล่าวไว้ข้างต้น ที่แย่กว่านั้นคือฉันทำงานในโครงการที่มีสี่ toolchain ที่แยกต่างหากที่ลอยอยู่รอบ ๆ เมื่อฉันได้รับการจ้าง - พวกเขาทั้งหมดใช้งานอย่างแข็งขัน ! หนึ่งในสิ่งแรกที่ฉันทำ (หลังจากที่ฉันได้รับบิลด์เพื่อทำงาน) ถูกวาง toolchain ภายใต้การควบคุมของแหล่งที่มา (ความคิดเกี่ยวกับระบบ CM ที่มั่นคงเกินความคาดหมาย)
และจะเกิดอะไรขึ้นเมื่อโครงการที่แตกต่างกันต้องใช้ชุดเครื่องมือที่แตกต่างกัน ตัวอย่างในประเด็น: หลังจากสองสามปีหนึ่งในโครงการได้รับการอัพเกรดจากผู้ขายและ Makefiles ทั้งหมดก็พัง ปรากฎว่าพวกเขาพึ่งพา GNU รุ่นใหม่กว่า ดังนั้นเราทุกคนอัพเกรด อ๊ะ Makefiles ของอีกโครงการหนึ่งพัง บทเรียน: ทำ GNU ทั้งสองเวอร์ชันแล้วเรียกใช้เวอร์ชันที่มากับการชำระเงินโครงการของคุณ
หรือถ้าคุณทำงานในสถานที่ที่ทุกสิ่งทุกอย่างอยู่นอกเหนือการควบคุมคุณมีบทสนทนาเช่น "เฮ้คนใหม่กำลังเริ่มวันนี้ซีดีสำหรับคอมไพเลอร์อยู่ที่ไหน" "Dunno ไม่เห็นพวกเขาตั้งแต่แจ็คลาออกเขาเป็นผู้พิทักษ์ซีดี" "เอ่อใช่ก่อนที่เราจะย้ายจากชั้น 2 มาก่อนเหรอ?" "บางทีพวกเขาอาจอยู่ในกล่องหรืออะไรบางอย่าง" และเนื่องจากเครื่องมือมีอายุสามปีจึงไม่มีความหวังว่าจะได้รับซีดีเก่าจากผู้ขาย
สคริปต์บิลด์ของคุณทั้งหมดอยู่ในการควบคุมซอร์ส ทุกอย่าง! ตลอดจนถึงตัวแปรสภาพแวดล้อม เครื่องสร้างของคุณควรจะสามารถเรียกใช้งานบิลด์ของโปรเจ็กต์ใด ๆ ของคุณได้โดยรันสคริปต์เดียวในรูทของโปรเจ็กต์ ( ./buildเป็นมาตรฐานที่สมเหตุสมผล./configure; makeเกือบจะดี) สคริปต์ควรตั้งค่าสภาพแวดล้อมตามที่ต้องการจากนั้นเปิดเครื่องมือใด ๆ ก็ตามที่สร้างผลิตภัณฑ์ (ทำ, ant, ฯลฯ )
หากคุณคิดว่ามันทำงานได้มากเกินไปก็ไม่เป็นเช่นนั้น อันที่จริงมันช่วยประหยัดงานได้มาก คุณส่งไฟล์ครั้งเดียวในตอนต้นและเมื่อใดก็ตามที่คุณอัปเกรด ไม่มีหมาป่าตัวเดียวที่สามารถอัพเกรดเครื่องของเขาเองและส่งมอบซอร์สโค้ดจำนวนมากซึ่งขึ้นอยู่กับเครื่องมือบางรุ่นล่าสุดทำลายการสร้างเพื่อคนอื่น ./buildเมื่อคุณจ้างนักพัฒนาใหม่คุณสามารถบอกพวกเขาจะตรวจสอบโครงการและเรียกใช้ เมื่อรุ่น 1.8 มีจำนวนมากของการปรับแต่งประสิทธิภาพและคุณปรับแต่งรหัสธงคอมไพเลอร์และตัวแปรสภาพแวดล้อมที่คุณต้องการเพื่อให้แน่ใจว่าธงคอมไพเลอร์ใหม่ไม่ได้ตั้งใจได้รับนำไปใช้กับรุ่น 1.7 แพทช์สร้างเพราะพวกเขาต้องการจริงๆรหัส การเปลี่ยนแปลงที่ไปพร้อมกับพวกเขาหรือคุณจะเห็นสภาพการแข่งขันที่มีขนดก
สิ่งที่ดีที่สุดก็คือการช่วยให้คุณประหยัดได้สักวันหนึ่ง: ลองคิดดูว่าคุณจะจัดส่งผลิตภัณฑ์เวอร์ชัน 3.0.2 ของคุณในวันจันทร์ ไชโยฉลอง ในเช้าวันอังคารลูกค้าวีไอพีโทรไปยังสายด่วนสนับสนุนโดยบ่นเกี่ยวกับบั๊กที่วิกฤตและเร่งด่วนในเวอร์ชั่น 2.2.6 ที่คุณจัดส่ง18 เดือนที่ผ่านมา และคุณยังคงต้องสนับสนุนตามสัญญาและพวกเขาปฏิเสธที่จะอัปเกรดจนกว่าคุณจะสามารถยืนยันได้ว่ามีการแก้ไขข้อบกพร่องในรหัสใหม่และมีขนาดใหญ่พอที่จะทำให้คุณเต้นได้ จักรวาลคู่ขนานมีสองแบบ:
ในจักรวาลที่คุณไม่มีไลบรารี toolchain และสร้างสคริปต์ในการควบคุมแหล่งและคุณไม่มีระบบ CM ที่มั่นคงแบบหินคุณสามารถตรวจสอบรหัสรุ่นที่ถูกต้อง แต่มันให้ คุณทุกข้อผิดพลาดเมื่อคุณพยายามสร้าง มาดูกันว่าเราอัพเกรดเครื่องมือในเดือนพฤษภาคมหรือไม่? ไม่นั่นคือห้องสมุด ตกลงกลับไปที่ห้องสมุดเก่า - รอมีการอัปเกรดสองรายการหรือไม่ อาใช่นั่นดูดีขึ้นเล็กน้อย แต่ตอนนี้ความผิดพลาด linker แปลกดูคุ้นเคย โอ้นั่นเป็นเพราะห้องสมุดเก่าไม่ทำงานกับ toolchain ใหม่นั่นเป็นสาเหตุที่เราต้องอัพเกรดใช่มั้ย (ฉันจะให้ความทุกข์ทรมานแก่คุณในส่วนที่เหลือของความพยายามมันใช้เวลาสองสัปดาห์และไม่มีใครมีความสุขที่จุดสิ้นสุดของมันไม่ใช่คุณไม่ใช่ผู้บริหารไม่ใช่ลูกค้า)
ในจักรวาลที่ทุกอย่างอยู่ในการควบคุมแหล่งที่มาคุณตรวจสอบแท็ก 2.2.6 มีการสร้างการดีบักพร้อมในหนึ่งชั่วโมงหรือประมาณนั้นใช้เวลาหนึ่งหรือสองวันในการสร้าง "ข้อผิดพลาดของวีไอพี" ใหม่ติดตามสาเหตุแก้ไขใน รุ่นปัจจุบันและโน้มน้าวใจลูกค้าให้อัพเกรด เครียด แต่ไม่เลวร้ายเท่ากับจักรวาลอื่น ๆ ที่เส้นผมของคุณสูงกว่า 3 ซม.
ด้วยที่กล่าวว่าคุณสามารถนำมันไปไกลเกินไป:
- คุณควรมีการติดตั้งระบบปฏิบัติการมาตรฐานที่คุณมี "สำเนาทองคำ" ของ เอกสารมันอาจจะอยู่ใน README ที่อยู่ในการควบคุมแหล่งที่มาเพื่อให้คนรุ่นต่อไปรู้ว่ารุ่น 2.2.6 และก่อนหน้านี้สร้างขึ้นเฉพาะบน RHEL 5.3 และ 2.3.0 และใหม่กว่าเท่านั้นที่สร้างขึ้นบน Ubuntu 11.04 ถ้ามันง่ายกว่าสำหรับคุณที่จะจัดการ toolchain ด้วยวิธีนี้ไปเลยแค่ให้แน่ใจว่ามันเป็นระบบที่เชื่อถือได้
- เอกสารโครงการมีความยุ่งยากในการบำรุงรักษาในระบบควบคุมแหล่งที่มา เอกสารโครงการอยู่ข้างหน้าโค้ดเสมอและไม่ใช่เรื่องแปลกที่จะทำงานกับเอกสารสำหรับเวอร์ชันถัดไปในขณะที่ทำงานกับโค้ดสำหรับเวอร์ชันปัจจุบัน โดยเฉพาะอย่างยิ่งหากเอกสารโครงการของคุณทั้งหมดเป็นเอกสารไบนารีที่คุณไม่สามารถกระจายหรือผสานได้
- หากคุณมีระบบที่ควบคุมเวอร์ชันของทุกสิ่งที่ใช้ในบิลด์ให้ใช้มัน ! ตรวจสอบให้แน่ใจว่าการซิงค์ทั่วทั้งทีมเป็นเรื่องง่ายเพื่อให้ทุกคน (รวมถึงเครื่องสร้าง) กำลังดึงจากชุดเครื่องมือเดียวกัน (ฉันกำลังคิดถึงระบบเช่นผู้สร้างของ Debian และการใช้ virtualenv ของ python อย่างรับผิดชอบ)