ฉันต้องการความช่วยเหลือเกี่ยวกับปรัชญาและการออกแบบการตั้งค่าการรวมระบบอย่างต่อเนื่อง
การตั้งค่า CI ปัจจุบันของเราใช้ buildbot เมื่อฉันเริ่มออกแบบมันฉันได้รับมรดก (ก็ไม่ใช่อย่างเคร่งครัดเนื่องจากฉันมีส่วนร่วมในการออกแบบเมื่อหนึ่งปีก่อน) ผู้สร้าง CI ตามความต้องการซึ่งได้รับการปรับแต่งให้ทำงานทั้งตัวในเวลาเดียวกันในชั่วข้ามคืน หลังจากนั้นไม่นานเราตัดสินใจว่าสิ่งนี้ไม่เพียงพอและเริ่มสำรวจกรอบ CI ที่แตกต่างกันในที่สุดก็เลือก buildbot หนึ่งในเป้าหมายของฉันในการเปลี่ยนไปเป็น buildbot (นอกเหนือจากการเพลิดเพลินไปกับความพิเศษทั้งหมดที่หวือ - ปัง) คือการเอาชนะความไม่เพียงพอของผู้สร้างรายต่อคืนที่ไม่หยุดยั้งของเรา
ขำขันฉันสักครู่แล้วให้ฉันอธิบายสิ่งที่ฉันได้รับมรดก codebase สำหรับ บริษัท ของฉันเป็นแอพพลิเคชั่น c ++ Windows ที่ไม่ซ้ำกันเกือบ 150 รายการโดยแต่ละรายการมีการพึ่งพาไลบรารีภายในหนึ่งโหลขึ้นไป (และอีกมากมายในไลบรารีของบุคคลที่สามเช่นกัน) บางไลบรารีเหล่านี้มีการพึ่งพาซึ่งกันและกันและมีแอพพลิเคชั่นที่ขึ้นอยู่กับว่า (ในขณะที่พวกเขาไม่มีส่วนเกี่ยวข้อง) จะต้องสร้างด้วยบิลด์เดียวกันของไลบรารีนั้น ครึ่งหนึ่งของแอปพลิเคชันและไลบรารีเหล่านี้ถูกพิจารณาว่าเป็น "ดั้งเดิม" และไม่สามารถถอดออกได้และจะต้องสร้างขึ้นด้วยการกำหนดค่าที่แตกต่างกันหลายอย่างของคอมไพเลอร์ IBM (ซึ่งฉันได้เขียนคลาสย่อยที่ไม่ซ้ำกันCompile) และอีกครึ่งหนึ่งShellCommands เนื่องจากไม่มีการรองรับ VSS)
ผู้สร้างรายกลางคืนดั้งเดิมของเราใช้แหล่งข้อมูลทุกอย่างและสร้างสิ่งต่าง ๆ ในลำดับที่แน่นอน ไม่มีวิธีในการสร้างเพียงแอปพลิเคชันเดียวหรือเลือกการแก้ไขหรือการจัดกลุ่มสิ่งต่าง ๆ มันจะเปิดตัวเครื่องเสมือนเพื่อสร้างจำนวนของแอปพลิเคชัน มันไม่ได้แข็งแกร่งมาก แต่ก็ไม่สามารถแจกจ่ายได้ มันไม่สามารถขยายได้อย่างน่ากลัว ฉันต้องการที่จะเอาชนะข้อ จำกัด เหล่านี้ทั้งหมดใน buildbot
แต่เดิมวิธีที่ฉันทำคือการสร้างรายการสำหรับแต่ละแอปพลิเคชันที่เราต้องการสร้าง (ทั้งหมด 150ish) จากนั้นสร้างตัวกำหนดตารางเวลาที่เรียกใช้ซึ่งสามารถสร้างแอปพลิเคชันต่าง ๆ เป็นกลุ่มจากนั้นให้รวมกลุ่มเหล่านั้น สิ่งเหล่านี้สามารถทำงานได้บนทาสเฉพาะ (ไม่มีเครื่องเสมือนจริงอีกต่อไป) และถ้าฉันต้องการฉันก็สามารถเพิ่มทาสใหม่ได้ ตอนนี้ถ้าเราต้องการสร้างงานเต็มรูปแบบตามกำหนดเวลาเพียงแค่คลิกเดียว แต่เราสามารถสร้างแอปพลิเคชันเดียวได้หากเราต้องการ
อย่างไรก็ตามมีจุดอ่อนสี่ประการของวิธีการนี้ หนึ่งคือเว็บการอ้างอิงที่ซับซ้อนของต้นไม้ต้นกำเนิดของเรา เพื่อให้การบำรุงรักษา config ง่ายขึ้นผู้สร้างทั้งหมดจะถูกสร้างขึ้นจากพจนานุกรมขนาดใหญ่ การพึ่งพาถูกดึงและสร้างขึ้นในรูปแบบที่ไม่รุนแรงมากนัก (กล่าวคือการปิดบางสิ่งในพจนานุกรมสร้างเป้าหมายของฉัน) อย่างที่สองคือแต่ละบิลด์มีขั้นตอนการบิลด์ระหว่าง 15 ถึง 21 ซึ่งยากที่จะเรียกดูและดูในเว็บอินเตอร์เฟสและเนื่องจากมีประมาณ 150 คอลัมน์จึงต้องโหลดตลอดเวลา (คิดตั้งแต่ 30 วินาทีถึงหลายนาที) ประการที่สามเราไม่มีการค้นพบเป้าหมายการสร้างโดยอัตโนมัติอีกต่อไป (แม้ว่าผู้ร่วมงานคนหนึ่งของฉันจะทำให้ฉันสับสนเกี่ยวกับเรื่องนี้ฉันไม่เห็นสิ่งที่ทำให้เราได้รับในตอนแรก) สุดท้าย
ตอนนี้ย้ายไปสู่การพัฒนาใหม่เราเริ่มใช้ g ++ และการโค่นล้ม (ไม่ใช่การย้ายพื้นที่เก็บข้อมูลเก่าโปรดคำนึงถึงคุณ - สำหรับสิ่งใหม่) นอกจากนี้เรากำลังเริ่มทำการทดสอบหน่วยเพิ่มเติม ("มากกว่า" อาจให้ภาพที่ไม่ถูกต้อง ... มันก็เหมือนๆ กัน ) และการทดสอบการรวม (โดยใช้ python) ฉันมีช่วงเวลาที่ยากลำบากในการหาวิธีการปรับให้พอดีกับการกำหนดค่าปัจจุบันของฉัน
ดังนั้นฉันไปผิดทางปรัชญาที่นี่ที่ไหน ฉันจะดำเนินการต่อได้ดีที่สุด (กับ buildbot - เป็นชิ้นส่วนของปริศนาที่ฉันมีสิทธิ์ใช้งานเท่านั้น) เพื่อให้การกำหนดค่าของฉันสามารถบำรุงรักษาได้จริง? ฉันจะจัดการกับจุดอ่อนของการออกแบบได้อย่างไร อะไรที่ใช้งานได้จริงในแง่ของกลยุทธ์ CI สำหรับรหัสฐานขนาดใหญ่ (อาจมากกว่า)
แก้ไข:
ฉันคิดว่าฉันอธิบายปัญหาของฉัน แต่เห็นได้ชัดว่าฉันยังไม่ชัดเจนพอ ฉันไม่ต้องการคำแนะนำสำหรับการเปลี่ยนแพลตฟอร์ม CI มันจะไม่เกิดขึ้นและคำตอบแนะนำว่าจะไม่ได้รับการยอมรับ สิ่งที่ฉันอยากรู้คือคนอื่นจัดการกับรหัสฐานที่ซับซ้อนโดยใช้ CI ได้อย่างไร ฉันมีผลิตภัณฑ์ที่แตกต่างกันสองโหลและฉันมีการพึ่งพาที่กระจัดกระจายไปตามลมและพวกมันต่างกันทั้งหมด นี่คือสิ่งที่ฉันต้องการทราบวิธีจัดการกับ