ทำอย่างไรถึงจะทำให้ลำตัวมั่นคงเมื่อการทดสอบใช้เวลานาน

เรามีห้องทดสอบสามชุด:

• ชุด "เล็ก" ใช้เวลาเพียงสองสามชั่วโมงในการทำงาน
• ชุด "กลาง" ที่ใช้เวลาหลายชั่วโมงโดยปกติแล้วจะวิ่งทุกคืน (ทุกคืน)
• ชุด "ใหญ่" ที่ใช้เวลาหนึ่งสัปดาห์ + ในการทำงาน

เรามีห้องทดสอบสั้นกว่านี้เยอะ แต่ฉันไม่ได้สนใจที่นี่

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

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

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

และมันจะสำคัญไหมถ้ามันเป็นระบบควบคุมแหล่งรวมส่วนกลางอย่าง SVN หรือระบบที่กระจายแบบ git?

โดยวิธีการที่ฉันเป็นนักพัฒนาจูเนียร์ที่มีความสามารถที่ จำกัด ในการเปลี่ยนแปลงสิ่งต่าง ๆ ฉันแค่พยายามที่จะเข้าใจว่ามีวิธีการจัดการกับความเจ็บปวดนี้ที่ฉันกำลังประสบ

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

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

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

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

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

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

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

ในการจัดการ flipside ของโครงสร้าง VCS ของคุณจะมีความซับซ้อนมากขึ้น แต่ในหนึ่งสัปดาห์เต็มสำหรับการทดสอบแบบเต็มของคุณฉันคิดว่าคุณสามารถรับความเจ็บปวดได้!

ฉันยังคงแนะนำให้ใช้กลยุทธ์สาขา "ที่มั่นคง" และ "การพัฒนา" ในบางรูปแบบหรืออื่น ๆ แต่มีหลายวิธีที่จะทำเรื่องนั้นและคุณสามารถเลือกอันที่ดีที่สุดสำหรับองค์กรของคุณ (meta-repositories ที่มีการแก้ไขถาวรชี้ไปที่ ที่เก็บแยกต่างหากสำหรับแต่ละหน่วยสาขาที่มั่นคงและสาขา dev สาขาคุณลักษณะ .... )

สำหรับ SVN ฉันไม่รู้เกี่ยวกับสิ่งนี้เช่น "pre-commit" ฉันคิดว่าเป็นไปได้ที่จะสร้างความมุ่งมั่นและย้อนกลับเมื่อการทดสอบล้มเหลว ด็อกเตอร์ - บราวน์กล่าวว่าวิธีเดียวที่จะทำได้ในสาขาชั่วคราวและรวมเข้ากับลำต้นในภายหลัง

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

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

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

การทดสอบสื่อที่ล้มเหลว: เป็นความจริงหรือไม่ที่การทดสอบเดียวกันส่วนใหญ่ล้มเหลว

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

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

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

คุณต้องทำให้การทดสอบของคุณทำงานเร็วขึ้นไม่มีวิธีอื่นในการจัดวงกลมนี้

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

นี่คือสิ่งที่ฉันแนะนำ:

1) ทำการทดสอบแบบ atmomic มากที่สุดและนำสภาพแวดล้อมกลับมาใช้ใหม่ให้สูงสุด

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

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

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

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

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

หรือมีระบบแบทช์ที่รับคำขอสำหรับสาขา / การแก้ไขเพื่อทดสอบ (จากที่ใดก็ได้ในทรี) และทดสอบพวกเขาและส่งไปยังลำต้น (หรือสาขาอื่น) หากผ่าน