การผสานรวมอย่างต่อเนื่อง - ข้อกำหนด

ต่อไปนี้เป็นรายการข้อกำหนดที่สำคัญที่สุดสำหรับการผสานรวมอย่างต่อเนื่อง

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

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

• Create a Comprehensive Automated Test Suite- หากคุณไม่มีชุดการทดสอบอัตโนมัติที่ครอบคลุมการสร้างที่ผ่านหมายความว่าแอปพลิเคชันสามารถรวบรวมและประกอบได้เท่านั้น ในขณะที่บางทีมนี่เป็นก้าวสำคัญ แต่จำเป็นอย่างยิ่งที่จะต้องมีการทดสอบอัตโนมัติในระดับหนึ่งเพื่อให้มั่นใจว่าแอปพลิเคชันของคุณใช้งานได้จริง

  โดยปกติจะมีการทดสอบ 3 ประเภทในการบูรณาการต่อเนื่อง ได้แก่ unit tests, component testsและ acceptance tests.

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

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

• Keep the Build and Test Process Short - หากใช้เวลานานเกินไปในการสร้างโค้ดและเรียกใช้การทดสอบหน่วยคุณจะพบปัญหาต่อไปนี้

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

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

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

• Don’t Check-In on a Broken Build- ข้อผิดพลาดที่ใหญ่ที่สุดของการผสานรวมอย่างต่อเนื่องคือการตรวจสอบในโครงสร้างที่เสียหาย หากบิวด์พังนักพัฒนาที่รับผิดชอบกำลังรอการแก้ไข พวกเขาระบุสาเหตุของการแตกหักโดยเร็วที่สุดและแก้ไขได้ หากเรานำกลยุทธ์นี้มาใช้เราจะอยู่ในตำแหน่งที่ดีที่สุดเสมอในการหาสาเหตุที่ทำให้เกิดความแตกแยกและแก้ไขทันที

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

• Always Run All Commit Tests Locally Before Committing- ตรวจสอบให้แน่ใจเสมอว่าการทดสอบที่ออกแบบมาสำหรับแอปพลิเคชันนั้นถูกรันบนเครื่องโลคัลก่อนที่จะรันบนเซิร์ฟเวอร์ CI เพื่อให้แน่ใจว่ามีการเขียนกรณีทดสอบที่ถูกต้องและหากมีความล้มเหลวในกระบวนการ CI นั่นเป็นเพราะผลการทดสอบที่ล้มเหลว

• Take Responsibility for All Breakages that Result from Your Changes- หากคุณทำการเปลี่ยนแปลงและการทดสอบทั้งหมดที่คุณเขียนผ่าน แต่คนอื่นพังงานสร้างก็ยังพัง โดยปกติจะหมายความว่าคุณได้นำเสนอข้อบกพร่องการถดถอยในแอปพลิเคชัน เป็นความรับผิดชอบของคุณเพราะคุณได้ทำการเปลี่ยนแปลง - แก้ไขการทดสอบทั้งหมดที่ไม่ผ่านอันเป็นผลมาจากการเปลี่ยนแปลงของคุณ ในบริบทของ CI สิ่งนี้ดูเหมือนชัดเจน แต่จริงๆแล้วมันไม่ใช่แนวทางปฏิบัติทั่วไปในหลาย ๆ โครงการ