6
กลยุทธ์การแยกส่วน Git ที่รวมเข้ากับกระบวนการทดสอบ / QA
ทีมพัฒนาของเราใช้กลยุทธ์GitFlow branching และมันยอดเยี่ยมมาก! เมื่อเร็ว ๆ นี้เราได้คัดเลือกผู้ทดสอบสองรายเพื่อปรับปรุงคุณภาพซอฟต์แวร์ของเรา แนวคิดคือผู้ทดสอบทุกคนควรทดสอบ / QA ในอดีตนักพัฒนาจะทำงานกับฟีเจอร์ในสาขาฟีเจอร์ที่แยกจากกันและรวมกลับไปที่developสาขาเมื่อเสร็จสิ้น นักพัฒนาจะทดสอบงานของเขาเองในfeatureสาขานั้น ๆ ตอนนี้สำหรับผู้ทดสอบเราเริ่มถามคำถามนี้ ผู้ทดสอบควรทดสอบคุณสมบัติใหม่ในสาขาใด เห็นได้ชัดว่ามีสองทางเลือก: ในแต่ละสาขาคุณลักษณะ ในdevelopสาขา การทดสอบในสาขาการพัฒนา ในขั้นต้นเราเชื่อว่านี่เป็นวิธีที่แน่นอนเพราะ: คุณลักษณะนี้ได้รับการทดสอบกับคุณลักษณะอื่น ๆ ทั้งหมดที่รวมเข้ากับdevelopสาขาตั้งแต่เริ่มการพัฒนา ความขัดแย้งใด ๆ สามารถตรวจพบได้เร็วกว่าในภายหลัง ทำให้งานของผู้ทดสอบง่ายขึ้นเขาจัดการกับสาขาเดียว ( develop) ตลอดเวลา เขาไม่จำเป็นต้องถามนักพัฒนาว่าสาขาใดสำหรับฟีเจอร์ใด (สาขาฟีเจอร์เป็นสาขาส่วนบุคคลที่จัดการโดยนักพัฒนาที่เกี่ยวข้องโดยเฉพาะและอิสระ) ปัญหาที่ใหญ่ที่สุดคือ: developสาขาปนเปื้อนมีข้อบกพร่อง เมื่อผู้ทดสอบพบข้อบกพร่องหรือข้อขัดแย้งเขาจะรายงานกลับไปยังผู้พัฒนาซึ่งเป็นผู้แก้ไขปัญหาในสาขาการพัฒนา (สาขาคุณลักษณะถูกละทิ้งเมื่อรวมเข้าด้วยกัน) และอาจต้องมีการแก้ไขเพิ่มเติมในภายหลัง การคอมมิชชันหรือการรวมในภายหลังหลาย ๆ ครั้ง (หากมีการสร้างสาขาใหม่จากdevelopสาขาอีกครั้งเพื่อแก้ไขจุดบกพร่อง) ทำให้การย้อนคุณสมบัติออกจากdevelopสาขาทำได้ยากมากหากทำได้ มีคุณสมบัติหลายอย่างที่รวมเข้าด้วยกันและได้รับการแก้ไขในdevelopสาขาในเวลาที่ต่างกัน สิ่งนี้ทำให้เกิดปัญหาใหญ่เมื่อเราต้องการสร้างรุ่นที่มีคุณลักษณะบางอย่างในdevelopสาขา การทดสอบในสาขาคุณลักษณะ ดังนั้นเราจึงคิดอีกครั้งและตัดสินใจว่าเราควรทดสอบฟีเจอร์ในสาขาฟีเจอร์ ก่อนที่เราจะทดสอบเราจะรวมการเปลี่ยนแปลงจากdevelopสาขาไปยังสาขาคุณลักษณะ (ตามลำดับdevelopสาขา) ดีจัง: คุณยังคงทดสอบคุณลักษณะนี้กับคุณลักษณะอื่น ๆ …