การต่อสู้และการพัฒนาที่มั่นคงสร้างความขัดแย้งหรือไม่?

11

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

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

การยืนยันแต่ละครั้งจะถูกตรวจสอบกับชุดการทดสอบพื้นฐาน เมื่อตรวจสอบแล้วการเปลี่ยนแปลงจะถูกส่งไปยังต้นแบบหลังจากตรวจสอบโค้ด (Gerrit)
การทดสอบหน่วยพื้นฐานทำงานทุก 30 นาทีระยะเวลาน้อยกว่า 10 นาที
การทดสอบการรวมจะทำงานทุก 2 ชั่วโมงและระยะเวลา 1 ชั่วโมง
UI- / Webtests ทำงานบนการทดสอบการรวมที่ประสบความสำเร็จใช้เวลาหลายชั่วโมง

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

ดังนั้นเราต้องการ:

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

รับ (2) คะแนน (1) และ (3) ดูเหมือนจะขัดแย้งกัน ใครบ้างมีวิธีปฏิบัติที่ดีในการจัดการกับเรื่องนี้?

( ขณะนี้เรากำลังคลายจุด (2) และอนุญาตให้สร้างต่อเนื่องแม้ในขั้นตอนการสร้างที่ล้มเหลวฉันยังไม่มีข้อเสนอแนะใด ๆ ที่มีผลต่อคุณภาพของเรา )

ขอบคุณ Simon

— ไซมอน
แหล่งที่มา

3

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

— zaitsman

สภาพแวดล้อมการสร้างของคุณอยู่ในสถานที่หรือตามเมฆ?

— Lauri Laanti

@LauriLaanti สภาพแวดล้อมการสร้างของเราอยู่ในสถานที่เช่น Jenkins 1 ตัวอย่างที่มี 3 ทาส

— Simon

7

หลักการพื้นฐานสองข้อแรก: - การเปลี่ยนแปลงที่สำคัญควรอยู่ในสาขาคุณลักษณะใน VCS ของคุณ - สาขาคุณลักษณะควรผ่านการทดสอบทั้งหมดก่อนที่จะรวมเข้ากับลำต้น เพิ่ม - คอมมิชชันควรสร้างเสมอ - บิลด์ที่ เสียหายต้องมีการดำเนินการทันทีจากผู้มอบหมาย & / หรือส่วนที่เหลือของทีม - การทดสอบที่ล้มเหลวควรยกเลิกการทดสอบที่เหลือหากเป็นการทดสอบที่สำคัญ

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

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

— สตีฟบาร์นส์
แหล่งที่มา

3

วิธีที่ดีในการเพิ่มที่นี่คือสาขาฟีเจอร์ควรผ่านการทดสอบทั้งหมดก่อนที่จะรวมเข้ากับการฉีด

— Bart van Ingen Schenau

@BartvanIngenSchenau - เพิ่มจุดดี!

— Steve Barnes

@SteveBarnes ขอบคุณสำหรับการป้อนข้อมูล ความมุ่งมั่นใน Gerrit นั้นอยู่ในสาขาเสมอและรวมเข้ากับความสำเร็จเท่านั้น (สัญลักษณ์แสดงหัวข้อย่อยแรกของฉันในกระบวนการสร้าง) หลังจากนั้นปัญหาก็จะเริ่มขึ้น ด้วย 30 devs ที่ยอมรับการเปลี่ยนแปลง mutliple ครั้งต่อวันเราต้องรวมก่อนแล้วจึงตรวจสอบ มีเป็นดำเนินการในทันทีหลังจากที่สร้างเสีย แต่เป็นช่วงเวลาระหว่างการกระทำและการสร้างข้อเสนอแนะคือ 2 ชั่วโมงจะมีหลายกระทำอื่น ๆ ในขณะเดียวกัน อาจทำลายการสร้างถัดไป

— Simon

@Simon จุดของ "ชื่อและความอัปยศ" คือการได้รับนักพัฒนาของคุณเพื่อหยุดการคอมมิชชันรหัส! ในระบบส่วนใหญ่เป็นไปได้ที่จะทำการทดสอบสร้างในระยะเวลาอันสั้นโดยใช้เครื่องมือเช่น ant, make, scons เป็นต้นหากโครงการของคุณมีโครงสร้างที่ดีภาษาส่วนใหญ่อนุญาตให้สร้างใหม่บางส่วนเพื่อทดสอบว่าสิ่งต่าง ๆ จะสร้างขึ้นหรือไม่ งานสร้างยังคงต้องทำแน่นอน)

— Steve Barnes

8

ไม่มีอะไรเกี่ยวข้องกับการต่อสู้ งานสร้างของคุณควรมีเสถียรภาพอย่างต่อเนื่องโดยไม่คำนึงถึง

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

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

— จอห์นวู
แหล่งที่มา

2

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

— ร. ว.

1

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

— John Wu

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

— Simon

6

ดูเหมือนว่าปัญหาของคุณคือการทดสอบใช้เวลานานเกินไป โชคดีที่กฎของมัวร์ได้ช่วยเราแก้ปัญหานั้น วันนี้ซีพียูเซิร์ฟเวอร์ระดับสูงอาจมีมากกว่า 10 คอร์ (และไฮเปอร์เธรดมากกว่า 10) อาจมี CPU หลายตัวในคอมพิวเตอร์เครื่องเดียว

หากฉันมีการทดสอบที่ใช้เวลานานฉันจะแก้ปัญหาด้วยฮาร์ดแวร์เพิ่มเติม ฉันจะซื้อเซิร์ฟเวอร์ระดับไฮเอนด์จากนั้นทำการทดสอบแบบขนานเพื่อให้การทดสอบใช้ประโยชน์จากคอร์ CPU ทั้งหมดอย่างเต็มที่ หากการทดสอบของคุณเป็นแบบเธรดเดี่ยววันนี้การใช้ประโยชน์จาก 10 คอร์และ 10 ไฮเปอร์เธรดอาจทำให้การทดสอบรันได้เร็วขึ้น 15 เท่า แน่นอนนี่หมายความว่าพวกเขายังใช้หน่วยความจำ 15 เท่าดังนั้นคอมพิวเตอร์ต้องมี RAM เพียงพอ

ดังนั้นเวลาหลายชั่วโมงจะเปลี่ยนเป็น 10-30 นาที

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

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

ฉันไม่เห็นการเชื่อมต่อระหว่างการต่อสู้กับปัญหาของคุณ ปัญหาอาจเกิดขึ้นจริงกับกระบวนการพัฒนาใด ๆ

— juhist
แหล่งที่มา

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

— Simon

การทดสอบบางอย่างอาจขัดแย้งกับการรันแบบขนาน

— deFreitas

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

— c_maker

2

เป็นไปไม่ได้ที่จะมีการติดตั้ง Jenkins เพิ่มเติมและให้ผู้พัฒนาทำการตรวจสอบ Jenkins แยกต่างหาก

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

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

— xyious
แหล่งที่มา

1

ดูเหมือนว่าจุด (2) จะเป็นจุดที่เจ็บปวดที่สุดดังนั้นฉันจะมุ่งเน้นไปที่

อาจถึงเวลาแบ่งโครงการออกเป็นหลาย ๆ โมดูล

https://en.wikipedia.org/wiki/Dependency_inversion_principle

A. โมดูลระดับสูงไม่ควรขึ้นอยู่กับโมดูลระดับต่ำ ทั้งสองควรขึ้นอยู่กับ abstractions

B. บทคัดย่อไม่ควรขึ้นอยู่กับรายละเอียด รายละเอียดควรขึ้นอยู่กับ abstractions

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

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

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

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

— rwong
แหล่งที่มา

0

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

รหัสมีการทดสอบหน่วย
ผ่านการทดสอบหน่วยเป็นส่วนหนึ่งของการสร้างอัตโนมัติ
รหัสถูกรวมเข้าเป็นหลัก (และแก้ไขข้อขัดแย้ง)
เป็นต้น

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

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

สำหรับ TFVC นั้นซับซ้อนกว่าเล็กน้อยเนื่องจากทุกสิ่งเกิดขึ้นที่ "remote" นั่นหมายความว่า devs ควรทำงานนอกกิ่งไม้เสมอเว้นแต่จะแก้ไขได้อย่างรวดเร็ว กฎเดียวกันนี้มีผลกับที่นี่เช่นเดียวกับ Git: ซอฟต์แวร์ที่ไม่สมบูรณ์ไม่ได้รับการยืนยัน ระยะเวลา ในการควบคุมเวอร์ชันที่ได้รับการจัดการอย่างถูกต้อง "หลัก" ควรจะสามารถ releasable ได้ตลอดเวลา หากความมุ่งมั่นได้ถูกทำให้เป็น "หลัก" นั่นหมายความว่าคุณทำไม่ถูก

— Chris Pratt
แหล่งที่มา