เซิร์ฟเวอร์รวมอย่างต่อเนื่อง ณ จุดใดที่น่าสนใจ

ฉันอ่านเกี่ยวกับเซิร์ฟเวอร์ CI เช่น Jenkins และฉันสงสัยว่า: มันมีประโยชน์ตรงไหน?

เพราะแน่นอนสำหรับโครงการขนาดเล็กที่คุณมีเพียง 5 ชั้นเรียนและการทดสอบ 10 หน่วยไม่มีความต้องการที่แท้จริง

ที่นี่เรามีการทดสอบประมาณ 1,500 เครื่องและพวกเขาผ่าน (บนเวิร์กสเตชัน Core 2 Duo เก่า) ในเวลาประมาณ 90 วินาที (เพราะพวกเขากำลังทดสอบ "หน่วย" จริง ๆ และรวดเร็วมาก) กฎที่เรามีคือเราไม่สามารถส่งรหัสเมื่อการทดสอบล้มเหลว

ดังนั้นนักพัฒนาซอฟต์แวร์แต่ละคนจึงเปิดการทดสอบทั้งหมดของเขาเพื่อป้องกันการถดถอย

เห็นได้ชัดว่าเนื่องจากนักพัฒนาทุกคนเปิดตัวการทดสอบทั้งหมดที่เราพบข้อผิดพลาดเนื่องจากการเปลี่ยนแปลงที่ขัดแย้งกันทันทีที่นักพัฒนารายหนึ่งดึงการเปลี่ยนแปลงของผู้อื่น (เมื่อมี)

ยังไม่ชัดเจนสำหรับฉัน: ฉันควรตั้งเซิร์ฟเวอร์ CI เช่น Jenkins หรือไม่ มันจะนำอะไรมา?

มันมีประโยชน์สำหรับการเพิ่มความเร็วหรือไม่ (ไม่ใช่ปัญหาในกรณีของเรา)

มีประโยชน์หรือไม่เพราะงานสร้างเก่าสามารถสร้างใหม่ได้? (แต่เราสามารถทำเช่นนี้กับ Mercurial โดยตรวจสอบ revs เก่า)

โดยทั่วไปฉันเข้าใจว่ามันมีประโยชน์ แต่ฉันก็ไม่เห็นว่าทำไม

คำอธิบายใด ๆ ที่คำนึงถึงคะแนนที่ฉันได้กล่าวไว้ข้างต้นจะได้รับการต้อนรับมากที่สุด

มันมีประโยชน์สำหรับการเพิ่มความเร็วหรือไม่ (ไม่ใช่ปัญหาในกรณีของเรา)

ทุกครั้งที่คุณขี่จักรยานกระบวนการของคุณคือเวลาที่คุณสามารถใช้ในการพัฒนากระบวนการ

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

มีประโยชน์หรือไม่เพราะงานสร้างเก่าสามารถสร้างใหม่ได้? (แต่เราสามารถทำเช่นนี้กับ Mercurial โดยตรวจสอบ revs เก่า)

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

คุณสร้างมันบนเซิร์ฟเวอร์สร้างตรงข้ามกับในกล่องของ Dev บางตัว

ที่นี่เรามีการทดสอบประมาณ 1,500 เครื่องและพวกเขาผ่าน (บนเวิร์กสเตชัน Core 2 Duo เก่า) ในเวลาประมาณ 90 วินาที (เพราะพวกเขากำลังทดสอบ "หน่วย" จริง ๆ และรวดเร็วมาก) กฎที่เรามีคือเราไม่สามารถส่งรหัสเมื่อการทดสอบล้มเหลว

นอกจากนี้คุณไม่ต้องการเรียกใช้การรวมอัตโนมัติหรือการทดสอบแบบ end-to-end ในรหัสของคุณและตรวจจับปัญหาที่การทดสอบหน่วยจะไม่จับ?

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

มันมีประโยชน์ตรงไหน?

เป็นการลงทุนแบบอื่น ๆ

ใช้ครั้งเดียวและคุณอาจออกมาข้างหลังหรือทำลายได้เท่ากัน ใช้ในหลายโครงการและคุณอาจจะออกมาข้างหน้า

ขึ้นอยู่กับประเภทของแอปพลิเคชันที่คุณใช้

หากคุณสร้างเว็บแอปพลิเคชันที่จำเป็นต้องปรับใช้กับ Java Application Server หรือ IIS ดังนั้น CI จึงกลายเป็นเกมที่เล่นง่าย เช่นเดียวกันถ้าคุณมีฐานข้อมูลเป็นส่วนหนึ่งของโครงการ การปรับใช้นั้นเจ็บปวดที่จะดำเนินการด้วยตนเองและทีมงาน QA ของคุณ (ถ้าคุณมี) จะต้องใช้บ่อยทุกวันในบางจุด

นอกจากนี้คุณอาจต้องการดูว่าความต้องการและปัญหาของคุณสอดคล้องกับ12 ขั้นตอนเพื่อรหัสที่ดีขึ้นของ Joel Spolskyอย่างไร โดยเฉพาะอย่างยิ่ง 2, 3 และ 10 (แม้ว่าพวกเขาจะน่าสนใจและสำคัญทั้งหมด)

มันมีประโยชน์ตรงไหน?

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

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

สำหรับฉันแล้ว CI จะน่าสนใจถ้าทีมของคุณมีสมาชิกมากกว่า 1 คน

คุณต้องหยุดคิดว่า CI เป็น "พีซีเครื่องอื่นที่ใช้ทดสอบสำหรับฉัน" CI เกี่ยวกับการมีกระบวนการสร้างที่กำหนดและอัตโนมัติและการจัดการปล่อย

CI เป็นหน่วยงานที่มีสิทธิ์เดียวที่สร้างการเปิดตัวซอฟต์แวร์ของคุณ ถ้ามันไม่ได้สร้างบน CI มันก็ไม่ได้เกิดขึ้น

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

ปัญหาที่หลีกเลี่ยง:

• ใครเป็นผู้รับผิดชอบในการสร้างการเปิดตัว
• เป็นคนนี้ใช้ได้ 24/7
• แต่มันสร้างจากซินโดรมของฉัน
• ลบความคลุมเครือทั้งหมดเกี่ยวกับเวอร์ชันที่เราเปิดตัว

ข้อดี (มากเกินไปที่จะพูดถึงทั้งหมด):

• การกำหนดหมายเลขเวอร์ชันอัตโนมัติ
• การรวมการติดตามปัญหา
• การสร้างตัวชี้วัดอัตโนมัติ
• การวิเคราะห์รหัสคงที่
• การปรับใช้อัตโนมัติ
• การตั้งค่าแบบหลายขั้นตอน

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

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

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

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

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

ฉันมีปัญหาเดียวกันนี้และนั่นคือสิ่งที่ทำให้ฉันพัฒนา Cintient ในเวลาว่างของฉันตั้งแต่ประมาณหนึ่งปีที่แล้ว สถานที่ตั้งของฉันคือทำให้ง่ายต่อการติดตั้งกำหนดค่าและใช้งานและเพื่อให้ส่งมอบในตัวชี้วัดคุณภาพเหล่านั้นที่ทุกคนอื่นล้มเหลวหรือต่ำกว่ามาก ดังนั้นหลังจากคำตอบยาว ๆ นี้มาถึงฉันก็ไม่มีที่ติเสียบชี้ไปที่ลิงค์ GitHub สำหรับโครงการ (ซึ่งเป็นฟรีและโอเพนซอร์ส, natch) นอกจากนี้ยังมีภาพหน้าจอที่ดี :-) https://github.com/matamouros/cintient

หวังว่าฉันช่วยคุณ

(หมายเหตุ: แก้ไขหลังจากความคิดเห็นของไบรอันโอ๊คลีย์บนความจริงที่ว่าฉันควรใช้เวลามากขึ้นในการสร้างคำตอบที่ดีกว่าฉันคิดว่าเขาพูดถูก)