การจัดการหลายสาขาในการรวมอย่างต่อเนื่อง

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

จนถึงตอนนี้ฉันพบว่ามี 2 แนวทางหลักที่ฉันสามารถทำได้ (หรืออาจจะเป็นวิธีอื่น ๆ ???)

• งานหลายชุด (พูดถึง Jenkins / Hudson ที่นี่) ต่อสาขา
  • เขียนเครื่องมือเพื่อจัดการงานพิเศษ
    • สร้าง / แก้ไข / ลบงานจำนวนมาก
    • การตั้งค่าแบบกำหนดเองสำหรับแต่ละงานต่อสาขา (SCM url, การทำสำเนาการจัดการ repos)
    • ตัวอย่างบางส่วนของผู้ที่แก้ไขปัญหานี้ด้วยเครื่องมือเชลล์สคริปต์มดและ Jenkins CLI ดู:
      1. http://jenkins.361315.n4.nabble.com/Multiple-branches-best-practice-td2306578.html
      2. http://jenkins.361315.n4.nabble.com/Is-it-possible-to-handle-multiple-branches-where-some-jobs-should-run-on-each-one-without-duplicatin-td954729 html
      3. http://jenkins.361315.n4.nabble.com/Parallel-development-with-branches-td1013013.html
      4. กำหนดค่าหรือสร้างงานฮัดสันโดยอัตโนมัติ
  • จะทำให้เกิดภาระมากขึ้นในคลัสเตอร์ CI ของคุณ
  • วงจรคำติชมสำหรับ devs ช้าลง (หากโครงสร้างพื้นฐานไม่สามารถรองรับการโหลดใหม่ได้)
• งานหลายชุดต่อ 2 สาขา (dev & stable)
  • จัดการสองชุดด้วยตนเอง (หากคุณเปลี่ยน Conf ของงานให้แน่ใจว่าได้เปลี่ยนในสาขาอื่น)
    • PITA แต่อย่างน้อยก็มีเพียงไม่กี่คนที่จะจัดการ
  • สาขาพิเศษอื่น ๆ จะไม่ได้รับชุดทดสอบเต็มรูปแบบก่อนที่จะถูกผลักดันไปยัง dev
  • ผู้พัฒนาที่ไม่พอใจ เหตุใดนักพัฒนาจึงควรสนใจเกี่ยวกับปัญหาการปรับขนาด CI เขามีคำของ่ายๆเมื่อฉันแยกสาขาฉันต้องการทดสอบรหัสของฉัน เรียบง่าย

ดูเหมือนว่าถ้าฉันต้องการให้ devs กับ CI สำหรับสาขาที่กำหนดเองของพวกเขาฉันต้องการเครื่องมือพิเศษสำหรับ Jenkins (API หรือ shellscripts หรืออะไรบางอย่าง?) และจัดการการปรับขนาด หรือฉันสามารถบอกให้พวกเขารวมเข้ากับ DEV ให้บ่อยขึ้นและใช้ชีวิตโดยไม่มี CI ในสาขาที่กำหนดเอง คุณจะเลือกอันไหนหรือมีทางเลือกอื่น

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

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

• ซ่อนฟังก์ชันใหม่จนกว่าจะเสร็จสิ้น (AKA Feature Toggles )
• ทำการเปลี่ยนแปลงทั้งหมดทีละน้อยเป็นชุดของการเปลี่ยนแปลงเล็ก ๆ ซึ่งแต่ละรายการสามารถแก้ไขได้
• ใช้ Branch by Abstraction เพื่อทำการเปลี่ยนแปลงขนาดใหญ่กับ codebase
• ใช้ส่วนประกอบเพื่อแยกส่วนของแอปพลิเคชันของคุณที่เปลี่ยนแปลงในอัตราที่แตกต่างกัน

พวกเขาค่อนข้างอธิบายตัวเองยกเว้นสาขาโดยนามธรรม นี่เป็นเพียงคำศัพท์เฉพาะสำหรับ:

1. สร้างสิ่งที่เป็นนามธรรมเหนือส่วนของระบบที่คุณต้องเปลี่ยนแปลง
2. Refactor ส่วนที่เหลือของระบบเพื่อใช้เลเยอร์นามธรรม
3. สร้างการนำไปใช้งานใหม่ซึ่งไม่ได้เป็นส่วนหนึ่งของเส้นทางรหัสการผลิตจนกว่าจะเสร็จสมบูรณ์
4. อัปเดตเลเยอร์นามธรรมของคุณเพื่อมอบสิทธิ์การใช้งานใหม่ของคุณ
5. ลบการใช้งานเก่า
6. ลบเลเยอร์นามธรรมออกหากไม่เหมาะสมอีกต่อไป

ย่อหน้าต่อไปนี้จากส่วนBranches, Streams และ Continuous Integrationในบทที่ 14: Advanced Version Controlสรุปผลกระทบ

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

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

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

หากคุณกังวลเกี่ยวกับการโหลดบนเซิร์ฟเวอร์ CI คุณสามารถตั้งค่าอินสแตนซ์ของ CI แยกกันหรือแม้แต่ทาสที่แยกจากกันเพื่อช่วยปรับสมดุลของโหลดในเซิร์ฟเวอร์หลายเครื่อง ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ที่คุณใช้งาน Hudson / Jenkins นั้นเพียงพอ ฉันใช้ Apache Tomcat และต้องแน่ใจว่ามีหน่วยความจำและพลังประมวลผลเพียงพอที่จะประมวลผลคิวบิลด์

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

ฉันจะเลือกสาขา dev + ที่มั่นคง และหากคุณยังต้องการสาขาที่กำหนดเองและกลัวการโหลดทำไมไม่ย้ายสาขาที่กำหนดเองเหล่านี้ไปยังระบบคลาวด์แล้วปล่อยให้นักพัฒนาจัดการด้วยตนเองเช่นhttp://cloudbees.com/dev.cb นี่คือ บริษัท ที่ Kohsuke อยู่ในขณะนี้ . นอกจากนี้ยังมี Eclipse Tooling ดังนั้นหากคุณใช้ Eclipse คุณจะรวมเข้ากับ dev env อย่างแน่นหนา

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

• สร้างที่เก็บสแน็ปช็อตแยกต่างหากใน nexus สำหรับแต่ละสาขาคุณลักษณะ
• แบ่งปันที่เก็บในเครื่องกับทาสเฉพาะ
• ใช้ repository-server-plugin กับที่เก็บอัพสตรีม
• สร้างทั้งหมดภายในงานเดียวด้วยที่เก็บส่วนตัวเดียว

ตามความเป็นจริงทางออกสุดท้ายมีแนวโน้มมากที่สุด วิธีแก้ปัญหาอื่น ๆ ทั้งหมดขาดไม่ทางใดก็ทางหนึ่ง เมื่อใช้ร่วมกับปลั๊กอิน job-dsl คุณสามารถตั้งค่าสาขาคุณลักษณะใหม่ได้อย่างง่ายดาย เพียงคัดลอกและวางสคริปต์ groovy ปรับเปลี่ยนสาขาและปล่อยให้งานเมล็ดสร้างงานใหม่ ตรวจสอบให้แน่ใจว่างานเริ่มต้นลบงานที่ไม่มีการจัดการ จากนั้นคุณสามารถปรับขนาดได้อย่างง่ายดายด้วยสาขาคุณลักษณะในโครงการ maven ต่างๆ

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

2 เซนต์ของฉัน