เป็นการดีหรือไม่ที่จะทำการทดสอบหน่วยใน hooks การควบคุมเวอร์ชัน?

จากมุมมองทางเทคนิคเป็นไปได้ที่จะเพิ่มตะขอกดล่วงหน้า / หลังบางอันซึ่งจะเรียกใช้การทดสอบหน่วยก่อนที่จะอนุญาตให้มีการรวมการมอบหมายเฉพาะกับสาขาเริ่มต้นระยะไกล

คำถามของฉันคือ - จะดีกว่าหรือไม่หากทำการทดสอบหน่วยในการสร้างไปป์ไลน์

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

ไม่ไม่ใช่ด้วยเหตุผลสองประการ:

ความเร็ว

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

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

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

จากจุดนั้นคุณสามารถจ่ายเพิ่ม $ 10,000 สำหรับเซิร์ฟเวอร์ที่ดีกว่าซึ่งจะลดเวลา แต่ไม่มากหรือรันการทดสอบบนเซิร์ฟเวอร์หลายเครื่องซึ่งจะชะลอตัวลงเท่านั้น

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

สิ่งที่คุณสามารถทำได้คือ:

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

  ตรวจสอบให้แน่ใจว่าการค้นหาการทดสอบที่เกี่ยวข้องและการใช้งานนั้นเป็นเรื่องง่าย (และรวดเร็ว) ตัวอย่างเช่น Visual Studio สามารถตรวจสอบว่าการทดสอบใดที่อาจได้รับผลกระทบจากการเปลี่ยนแปลงที่เกิดขึ้นตั้งแต่การดำเนินการครั้งสุดท้าย IDE / แพลตฟอร์ม / ภาษา / กรอบงานอื่น ๆ อาจมีฟังก์ชั่นที่คล้ายกัน

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

• เรียกใช้การทดสอบหน่วยบนเซิร์ฟเวอร์การรวมอย่างต่อเนื่องของคุณ

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

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

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

ความปลอดภัย

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

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

ให้ฉันเป็นคนที่ไม่เห็นด้วยกับผู้ตอบคำถามของฉัน

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

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

ทำไม?

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

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

ใช่ต้องใช้เวลาในการสร้างและเรียกใช้การทดสอบ จากประสบการณ์ของฉัน 5-10 นาทีสำหรับแอป C # ที่มีขนาดเหมาะสมและการทดสอบยูนิต ~ 5k และฉันไม่สนใจสิ่งนั้น ใช่ผู้คนควรเช็คอินบ่อยๆ แต่พวกเขาก็ควรปรับปรุงงานของพวกเขาบ่อยครั้งหรือตรวจสอบอีเมลของพวกเขาหรือรับกาแฟหรืออื่น ๆ อีกหลายสิบ "ไม่ทำงานกับรหัส" สิ่งที่ทำให้งานของวิศวกรซอฟต์แวร์ที่จะครอบครองในเวลานั้น การตรวจสอบรหัสที่ไม่ดีนั้นมีค่าใช้จ่ายสูงเกินกว่า 5-10 นาที

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

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

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

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

ที่เกี่ยวข้อง: ฉันควรมีการทดสอบหน่วยสำหรับข้อบกพร่องที่รู้จักหรือไม่? และค่าของการตรวจสอบในการทดสอบหน่วยล้มเหลวคืออะไร?

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

อย่างไรก็ตามโซลูชันเฉพาะของการผูก hooks ไม่ใช่แผนที่ดี

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

ไม่คุณไม่ควรทำตามคำตอบอื่น ๆ

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

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

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

• มีสาขาที่เตรียมไว้ซึ่งคุณสามารถคอมมิวนิตี้ระหว่างสาขา dev ของคุณและสาขาหลักเท่านั้น

• การตั้งค่า hook ที่เริ่มต้นหรือเข้าคิวการ build และการทดสอบบนคอมมิตที่ทำบน staging branch แต่ไม่ได้ทำให้การรอคอมมิชชัน

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

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

เป็นผลให้:

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

  อย่างน้อยที่สุดคุณสามารถมั่นใจได้ว่าจะไม่มีใครทำอย่างไม่ตั้งใจหรือไม่มีความอาฆาตพยาบาท คุณไม่ควรพยายามทำเช่นนั้น

• คุณจะต้องเลือกระหว่าง:

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

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

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

  • การแสดงละครหลายสาขาซึ่งจะช่วยให้การรวมกันที่ประสบความสำเร็จไม่ขัดแย้งกันเพื่อไปยังสาขาหลัก

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

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

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

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

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

คุณจะต้องมีกรอบงานสร้างที่แคชสิ่งประดิษฐ์

คุณจะต้องใช้กรอบการทดสอบที่แคชสถานะการทดสอบจากการทดสอบ (สำเร็จ) พร้อมสิ่งประดิษฐ์ที่กำหนด

ด้วยวิธีนี้การเช็คอินที่ผ่านการทดสอบหน่วยจะรวดเร็ว (cross-check จากแหล่งข้อมูลไปยังสิ่งประดิษฐ์ที่สร้างขึ้นเมื่อนักพัฒนาตรวจสอบการทดสอบก่อนการเช็คอิน) ผู้ที่มีการทดสอบหน่วยที่ล้มเหลวจะถูกบล็อกและนักพัฒนาที่ อย่าลืมตรวจสอบบิลด์ก่อนการคอมมิชชันจะได้รับการสนับสนุนให้จำการทำเช่นนั้นในครั้งต่อไปเพราะวงจรคอมไพล์และทดสอบมีความยาว

ฉันจะบอกว่ามันขึ้นอยู่กับโครงการและขอบเขตของการทดสอบอัตโนมัติที่ทำงานบน "กระทำ"

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

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

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

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

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

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

ตัวอย่างบางส่วน:

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