เราจะหลีกเลี่ยงการพัฒนาที่ขับเคลื่อนด้วย CI ได้อย่างไร?


45

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

โครงการประกอบด้วยโครงร่าง "แกนกลาง" ซึ่งมีรหัสครึ่งหนึ่งของรหัสครึ่งหนึ่งกลุ่มของ "ปลั๊กอิน" ซึ่งได้รับการบำรุงรักษาโดยสมาคมและปลั๊กอินภายนอกหลายแห่งซึ่งส่วนใหญ่เราไม่ได้ทำ ไม่รู้ตัวด้วยซ้ำ

ปัจจุบัน CI ของเราสร้างหลักและปลั๊กอินบำรุงรักษา

หนึ่งในปัญหาใหญ่ที่เราเผชิญคือผู้ให้ข้อมูลส่วนใหญ่ (และโดยเฉพาะอย่างยิ่งในบางครั้ง) ไม่สร้าง 90% ของปลั๊กอินที่บำรุงรักษาดังนั้นเมื่อพวกเขาเสนอการเปลี่ยนแปลงโครงสร้างในแกนกลาง (ซึ่งสิ่งเหล่านี้เกิดขึ้นเป็นประจำ) พวกเขาตรวจสอบว่ารหัสรวบรวมในเครื่องของพวกเขาก่อนที่จะทำการร้องขอการดึงบน GitHub

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

ปลั๊กอินนั้นอาจมีการพึ่งพาไลบรารีของบุคคลที่สามเช่นCUDAเป็นต้นและผู้ใช้ไม่ต้องการไม่ทราบวิธีการหรือไม่สามารถทำได้ด้วยเหตุผลด้านฮาร์ดแวร์รวบรวมปลั๊กอินที่ใช้งานไม่ได้

ดังนั้น - ทั้ง PR ยังคงโฆษณาอยู่ในบริเวณขอบของPRs ที่ไม่เคยถูกผสาน- หรือผู้มีส่วนร่วม greps ตัวแปรที่ถูกเปลี่ยนชื่อในแหล่งที่มาของปลั๊กอินที่เสียหาย, เปลี่ยนรหัส, กดรหัสบนสาขาของเขา / เธอรอ CI ที่จะทำการรวบรวมให้เสร็จสิ้นมักจะได้รับข้อผิดพลาดมากขึ้นและทำซ้ำกระบวนการจนกว่า CI จะมีความสุข - หรือหนึ่งในสองของผู้จองที่จองเกินจำนวนที่มีอยู่แล้วในกลุ่มให้มือและพยายามแก้ไข PR บนเครื่องของพวกเขา

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


84
กฎสูงสุดของการจัดเตรียมปลั๊กอิน API ให้กับระบบคือมันถูกเก็บไว้อย่างเสถียรหรือเข้ากันได้อย่างน้อยย้อนหลัง การเปลี่ยนแปลงในคอร์โดยไม่มีการเปลี่ยนแปลงใด ๆ กับ API API จะไม่ทำลายการรวบรวมปลั๊กอินใด ๆ (มันอาจเกิดขึ้นได้ว่ามันจะหยุดการทำงานโดยไม่ตั้งใจ แต่ไม่ใช่การรวบรวม) หากการเปลี่ยนแปลงชื่อตัวแปรภายในคอร์อย่างง่ายสามารถนำไปสู่การรวบรวมปลั๊กอินที่ขาดได้การแยกระหว่างปลั๊กอินและคอร์ดูเหมือนจะไม่สมบูรณ์
Doc Brown


1
@KevinKrumwiede: ฉันแน่ใจว่าพวกเขารู้สิ่งนี้อยู่แล้ว ;-) หากคุณประสบความไม่ลงรอยกันฉันค่อนข้างมั่นใจว่าพวกเขาเปลี่ยน API โดยเจตนา
Doc Brown

3
ฉันจะเรียบเรียงคำถามใหม่เพราะมันทำให้เข้าใจผิดจริงๆ บางอย่างเช่นฉันจะจัดการ PRs ได้อย่างไรเมื่อพวกเขาทำลาย CI ปัจจุบันของเรา ฉันคิดว่าสถานการณ์ของคุณดีขึ้น
bracco23

2
กระบวนการสร้าง / ทดสอบของคุณยาก / ซับซ้อนเพียงใด มันควรจะเป็นเรื่องของการเรียกใช้คำสั่งเดียวหรือคลิกปุ่มเดียว ณ จุดนี้มันมีเหตุผลที่จะคาดหวังให้ผู้ใช้ทำการทดสอบทั้งหมดด้วยตนเองก่อนที่จะส่ง PR
Alexander

คำตอบ:


68

การพัฒนาที่ขับเคลื่อนด้วย CI นั้นใช้ได้! มันดีกว่าไม่ใช้การทดสอบและรวมถึงรหัสที่ใช้งานไม่ได้! อย่างไรก็ตามมีบางสิ่งที่จะทำให้ง่ายขึ้นสำหรับทุกคนที่เกี่ยวข้อง:

  • กำหนดความคาดหวัง:มีเอกสารสนับสนุนที่อธิบายว่า CI มักพบปัญหาเพิ่มเติมและสิ่งเหล่านี้จะต้องได้รับการแก้ไขก่อนทำการผสาน อาจอธิบายได้ว่าการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ ในท้องถิ่นมีแนวโน้มที่จะทำงานได้ดีขึ้นดังนั้นการแบ่งการเปลี่ยนแปลงขนาดใหญ่ในหลาย ๆ PR จึงเป็นเรื่องที่สมเหตุสมผล

  • ส่งเสริมการทดสอบในท้องถิ่น:ทำให้ง่ายต่อการตั้งค่าสภาพแวดล้อมการทดสอบสำหรับระบบของคุณ สคริปต์ที่ตรวจสอบว่ามีการติดตั้งการอ้างอิงทั้งหมดหรือไม่ คอนเทนเนอร์ Docker ที่พร้อมใช้งานหรือยัง ภาพเครื่องเสมือนจริงหรือ นักวิ่งทดสอบของคุณมีกลไกที่อนุญาตให้มีการจัดลำดับความสำคัญการทดสอบที่สำคัญกว่าหรือไม่?

  • อธิบายวิธีใช้ CI ด้วยตนเอง:ส่วนหนึ่งของความขัดข้องคือความคิดเห็นนี้เกิดขึ้นหลังจากส่ง PR เท่านั้น หากผู้มีส่วนร่วมตั้งค่า CI สำหรับที่เก็บของตนเองพวกเขาจะได้รับข้อเสนอแนะก่อนหน้านี้และสร้างการแจ้งเตือน CI ให้กับผู้อื่นน้อยลง

  • แก้ไข PRs ทั้งหมดด้วยวิธีใดวิธีหนึ่ง: หากบางสิ่งไม่สามารถผสานได้เนื่องจากมันเสียและหากไม่มีความคืบหน้าในการแก้ไขปัญหาให้ปิดเพียงแค่ การประชาสัมพันธ์แบบเปิดที่ถูกทิ้งร้างเหล่านี้ทำให้ทุกอย่างยุ่งเหยิงและข้อเสนอแนะใด ๆ ก็ดีกว่าการเพิกเฉยต่อปัญหา เป็นไปได้ที่วลีนี้จะดีมากและทำให้ชัดเจนว่าคุณยินดีที่จะผสานเมื่อปัญหาได้รับการแก้ไข (ดูเพิ่มเติมที่: ศิลปะแห่งการปิดโดยเจสซี Frazelle , ปฏิบัติที่ดีที่สุดสำหรับ Maintainers: เรียนรู้ที่จะบอกว่าไม่มี )

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

สำหรับมุมมองระยะยาวการเปลี่ยนแปลงนั้นดูเหมือนจะทำลายฟังก์ชันการทำงานที่ไม่เกี่ยวข้องดังนั้นบ่อยครั้งอาจหมายความว่าการออกแบบปัจจุบันของคุณเป็นปัญหาเล็กน้อย ตัวอย่างเช่นอินเทอร์เฟซปลั๊กอินทำแค็ปซูลภายในแกนหลักของคุณอย่างถูกต้องหรือไม่? C ++ ทำให้ง่ายต่อการรั่วไหลของรายละเอียดการใช้งานโดยไม่ตั้งใจ แต่ยังทำให้สามารถสร้าง abstractions ที่แข็งแกร่งซึ่งยากต่อการใช้งานในทางที่ผิด คุณไม่สามารถเปลี่ยนแปลงสิ่งนี้ข้ามคืนได้ แต่คุณสามารถเลี้ยงวิวัฒนาการระยะยาวของซอฟต์แวร์ไปสู่สถาปัตยกรรมที่มีความเปราะบางได้น้อยกว่า


13
"สิ่งเหล่านี้ที่ถูกทอดทิ้งประชาสัมพันธ์เปิดเพียงถ่วงทุกอย่าง" ฉันหวังว่าผู้ดูแลมากขึ้นมีทัศนคตินี้😔
GammaGames

34

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

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


20
CI ควรมีการทดสอบอัตโนมัติ หากคุณต้องการให้แน่ใจว่าปลั๊กอินมีส่วนต่อประสานที่เหมือนกันทุกตัวควรมีส่วนร่วมในการทดสอบที่แสดงส่วนต่อประสานที่พวกเขาต้องการ มาทางนี้และเมื่ออินเทอร์เฟซเปลี่ยนซึ่งจะทำคุณจะรู้ว่าปลั๊กอินใดที่คุณกำลังแตก ให้การทดสอบเหล่านี้แก่ฉันเพื่อทำงานในพื้นที่และฉันจะรู้ว่าฉันกำลังทำอะไรอยู่ก่อนที่ฉันจะออก PR
candied_orange

1
@lagarkane ความชัดเจนเป็นปัญหานโยบายมากกว่าด้านเทคนิค มีซอฟต์แวร์ที่ออกมาเหมือนอย่างคุณเพียงแค่ละทิ้งพฤติกรรมก่อนหน้านี้ในการอัปเกรด Perl5 เข้ากันไม่ได้กับ Perl6, Python2.7 ไม่สามารถใช้งานร่วมกับ Python3.4 ได้อย่างเต็มที่แล้วมีซอฟต์แวร์ที่สิ่งที่เกิดขึ้นยังคงสนับสนุนรหัสเก่า คุณยังคงสามารถเรียกใช้โค้ดจาวาสคริปต์เกือบทั้งหมดที่เขียนขึ้นสำหรับ Netscape Navigator 4 ในเบราว์เซอร์สมัยใหม่ ภาษาโปรแกรม Tcl สามารถใช้งานร่วมกับ backwords ได้เมื่อเทียบกับเวอร์ชั่นดั้งเดิม ฯลฯ ...
slebetman

3
@lagarkane: การรวมกลุ่มเป็นขั้นตอนในทิศทางที่ถูกต้องและหากสมาชิกแกนมุ่งเน้นพลังงานของพวกเขาในการแกะสลักอินเทอร์เฟซเหล่านี้คุณสามารถควบคุมพลังของปริญญาเอกและฝึกงานในอนาคตเพื่อให้โครงการของคุณแข็งแกร่ง :)
คาซาบลังกา

4
@Fattie: ใช้งานได้กับ Apple เพราะพวกเขาสร้างผลิตภัณฑ์ที่ประสบความสำเร็จสำหรับผู้บริโภคและนักพัฒนาถูกบังคับให้เล่นถ้าพวกเขาต้องการเป็นส่วนหนึ่งของมัน ไม่น่าเป็นไปได้ที่นักพัฒนาซอฟต์แวร์เหล่านั้นชอบทำลายการเปลี่ยนแปลงและไม่ใช่โมเดลที่ดีสำหรับโครงการโอเพ่นซอร์ส
คาซาบลังก้า

1
@casablanca ทั้งเชื้อสาย MacOS และ WindowsOS ประสบความสำเร็จอย่างมหาศาล (เนื้อหาสองผลิตภัณฑ์ที่ยิ่งใหญ่ที่สุดในแง่ดอลลาร์ที่แท้จริงในการดำรงอยู่ของมนุษย์) ในช่วงทศวรรษที่ผ่านมาพวกเขามีวิธีที่ตรงกันข้ามอย่างแน่นอน เห็นได้ชัดว่าทั้งคู่ประสบความสำเร็จ!
Fattie

8

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

โครงการของคุณมีcontributing.mdหรือคล้ายกันเพื่อช่วยเหลือผู้มีส่วนร่วมใหม่และเป็นครั้งคราวในการเตรียมการมีส่วนร่วมของพวกเขา? คุณมีรายการที่ชัดเจนปลั๊กอินใดที่เป็นส่วนหนึ่งของแกนกลางและจำเป็นต้องใช้งานร่วมกันได้หรือไม่?

หากเป็นการยากที่จะสร้างทุกสิ่งบนเครื่องเนื่องจากการพึ่งพาและอื่น ๆ คุณอาจคิดถึงการสร้างอิมเมจ docker ที่พร้อมใช้งานเป็นสภาพแวดล้อมการสร้างเพื่อให้ผู้มีส่วนร่วมใช้งาน


1
ขอบคุณสำหรับการตอบกลับ! ใช่เรามีแนวทางสนับสนุนที่เปิดเผยต่อสาธารณชน แต่ไม่ได้แสดงรายการปลั๊กอินตามที่คุณแนะนำซึ่งเป็นแนวคิดที่ดีอยู่แล้ว การทำให้ภาพนักเทียบท่าดูเหมือนจะเป็นการปรับปรุงที่ดีสำหรับกระบวนการช่วยเหลือในปัจจุบันอยู่แล้ว! ขอบคุณสำหรับการป้อนข้อมูล
lagarkane

8

ดังนั้นเมื่อพวกเขาเสนอให้มีการเปลี่ยนแปลง refactoring ในแกนกลาง (ซึ่งสิ่งเหล่านี้เกิดขึ้นเป็นประจำ) พวกเขาตรวจสอบว่าโค้ดคอมไพล์บนเครื่องของพวกเขาก่อนที่จะทำการดึง pull บน github

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

ฉันจะเสนอกฎว่า "การเปลี่ยนแปลง API ทั้งหมดต้องได้รับการวางแผนล่วงหน้า": ถ้า PR เข้ามาซึ่งทำให้การเปลี่ยนแปลงย้อนหลังเข้ากันไม่ได้กับ API จากบุคคลที่ไม่ได้ติดต่อกับผู้ดูแลเพื่อยอมรับแนวทางล่วงหน้า ก็ถูกปิดและผู้ส่งชี้ไปที่กฎ

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

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


2

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

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

ปัญหาการออกแบบจะเป็นการดีที่จะแก้ไข แต่เป็นมุมฉากของปัญหานี้


2

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

ปลั๊กอินนั้นอาจมีการพึ่งพาไลบรารีของบุคคลที่สามเช่น CUDA เป็นต้นและผู้ใช้ไม่ต้องการไม่ทราบวิธีการหรือไม่สามารถใช้เหตุผลด้านฮาร์ดแวร์รวบรวมปลั๊กอินที่ใช้งานไม่ได้

วิธีการแก้ปัญหาของคุณเป็นเรื่องง่าย: ลดอุปสรรคในการมีส่วนร่วม

วิธีที่ง่ายที่สุดในการ (1) เพิ่มความเร็วรอบการแก้ไขการทดสอบการคอมไพล์และ (2) ความแตกต่างของสภาพแวดล้อมที่ราบรื่นคือการให้เซิร์ฟเวอร์แบบบิลด์ :

  • รับเครื่องเนื้อ: 24, 48 หรือ 96 แกน, 2GB RAM / core, SSD เพื่อเพิ่มความเร็วในการรวบรวม
  • มั่นใจได้ว่าพวกเขามีฮาร์ดแวร์ที่เหมาะสม: FPGA, กราฟิกการ์ด, สิ่งที่จำเป็น
  • สร้างอิมเมจ Docker พร้อมไลบรารีซอฟต์แวร์ที่จำเป็นทั้งหมดที่ติดตั้งไว้ล่วงหน้า

จากนั้นเปิดเซิร์ฟเวอร์บิลด์เหล่านั้นให้กับผู้มีส่วนร่วม พวกเขาควรจะสามารถลงชื่อเข้าใช้จากระยะไกลในอิมเมจ Docker ใหม่และทำการทดสอบแก้ไขคอมไพล์จากเครื่องนี้จากระยะไกล

แล้ว:

  • พวกเขาไม่มีข้อแก้ตัวสำหรับการไม่สร้าง / ทดสอบปลั๊กอินที่บำรุงรักษา: มีทุกสิ่งที่พร้อมใช้งาน
  • พวกเขาไม่ต้องรอการตอบรับที่ยาวนานด้วย PRS ที่ขับเคลื่อนด้วย CI พวกเขามีการคอมไพล์ที่เพิ่มขึ้นและความสามารถในการดีบั๊ก (แทนที่จะคาดเดา)

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


ที่มา: การทำงานกับซอฟต์แวร์โดยใช้ FPGAs เนื่องจากราคาของสัตว์ร้ายและความหลากหลายของโมเดลที่เราต้องการคุณจะไม่พบ FPGA แต่ละรุ่นที่ติดตั้งในเครื่องของนักพัฒนาทุกคน


1

หากการสนับสนุนหลักโดยไม่มีการเปลี่ยนแปลงสัญญาใด ๆ สามารถทำลายซอฟต์แวร์ขึ้นอยู่กับว่ามันแสดงให้เห็นว่า:

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

ปัญหาทั้งสองควรแก้ไขได้ง่าย แต่คุณพูดถึงทีมหลักอาจไม่มีความสามารถในการทำเช่นนั้น ทางเลือกหนึ่งคือขอความช่วยเหลือจากชุมชนในการแก้ไขปัญหา


1

ดูเหมือนจะไม่มีใครยกเรื่องนี้ขึ้นมาเพื่อแก้ปัญหา

  • รายการปลั๊กอินทั้งหมดที่คุณสามารถเข้าถึง
  • เรียกใช้การทดสอบทั้งหมดที่ปลั๊กอินเหล่านี้กำหนด
  • บันทึกคำขอ / ตอบกลับ / การโต้ตอบทั้งหมดระหว่างคอร์และปลั๊กอินทั้งหมด
  • เก็บบันทึกเหล่านั้นตอนนี้เป็นการทดสอบความเข้ากันได้คร่าวๆ

เมื่อพัฒนาแกนหลักสนับสนุนให้นักพัฒนารันการทดสอบความเข้ากันได้เหล่านี้ หากพวกเขาล้มเหลวไม่ได้เช็คอิน

สิ่งนี้จะไม่รับประกันความเข้ากันได้ 100% แต่จะจับปัญหาได้มากขึ้นและเร็วขึ้น

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


0

ฉันมีปัญหาในการทำความเข้าใจสถานการณ์ที่ดูเหมือนจะเป็น: CI สร้างเพียงสาขาเดียว?

มีเหตุผลที่คุณไม่สามารถสร้างมากกว่าหนึ่งสาขาด้วย CI ได้หรือไม่?

ทางออกที่ง่ายที่สุดสำหรับปัญหานี้คือทำให้ผู้ให้ข้อมูลรายใดก็ตามสามารถเรียกใช้ CI build บนสาขาคุณลักษณะของเขา / เธอได้

จากนั้นคุณเพียงแค่ต้องการสร้าง CI ที่ประสบความสำเร็จในสาขาฟีเจอร์เพื่อให้การยอมรับการดึงของสาขานั้นเป็นที่ยอมรับ


ดูเหมือนว่าจะสรุปปัญหา
Fattie

1
คำถามบอกว่า "หรือผู้มีส่วนร่วม [... ] เปลี่ยนรหัสดันบนสาขาของเขา / เธอรอให้ CI ทำการรวบรวมให้เสร็จสิ้นมักจะได้รับข้อผิดพลาดมากขึ้นและทำซ้ำกระบวนการจนกว่า CI จะมีความสุข" - ดังนั้นฉันคิดว่านี่ เป็นปัญหาอยู่แล้ว แต่ปัญหาคือว่ามันค่อนข้างเจ็บปวดในการพัฒนาด้วยวงจรการแก้ไขข้อบกพร่องอันยาวนาน
npostavs

@npostavs ขอบคุณฉันเดาว่านั่นคือสิ่งที่ฉันพลาดครั้งแรกหรือสองครั้งที่ฉันอ่าน ถึงกระนั้น ... ฉันคิดว่าฉันดูเหมือนจะไม่เป็นปัญหา มีการพึ่งพาอาศัยกันมากมายพวกเขาไม่สามารถถูกทำลายได้ดังนั้นผู้มีส่วนร่วมจำเป็นต้องเข้ากันได้กับพวกเขาทั้งหมด นั่นเป็นธรรมชาติของซอฟต์แวร์ขนาดใหญ่ แน่นอนว่าสามารถทำงานได้เพื่อทำให้การสร้างเร็วขึ้นบางทีอาจเป็นอย่างอื่น แต่จะมีทางลัดใด
Kyralessa
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.