มีเครื่องมือ CI ที่รับประกันการถดถอยในระดับคุณภาพสาขาหรือไม่?


10

ตามเนื้อผ้าระบบ CI จะทำการตรวจสอบระดับคุณภาพในสาขาบูรณาการเท่านั้นโดยดำเนินการตรวจสอบ QA บนรหัสฐานที่มีการเปลี่ยนแปลงเกิดขึ้นแล้วคอยเฝ้าดูการถดถอยและส่งการแจ้งเตือนสำหรับการแทรกแซงของมนุษย์

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

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

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


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

@ Pierre.Vriens นี่ดีกว่าไหม?
Dan Cornilescu

คำตอบ:


6

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

Atlassian มีแอปพลิเคชั่นที่น่าสนใจของ Git hooks :

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

หากคุณใช้ Git ตะขอนั้นมีประสิทธิภาพมาก (และมี hooks ที่คล้ายกันสำหรับSVN , Mercurialและระบบควบคุมรุ่นอื่น ๆ ) และคุณอาจพบว่ามีประโยชน์ในการใช้การเรียกใช้การตรวจสอบการยืนยันล่วงหน้า

เอกสาร Git มีหน้าเกี่ยวกับการสร้าง hook เพื่อปฏิเสธ push หากไม่ตรงตามเกณฑ์ที่กำหนดซึ่งสามารถปรับให้เข้ากับกรณีการใช้งานนี้ได้อย่างง่ายดาย

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

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


ภาพ sw ที่ดีคืออะไรที่สร้างขึ้น แต่ DOA จากการทดสอบที่คาดหวัง ผู้พัฒนาไม่สามารถทดสอบการเปลี่ยนแปลงรหัสของพวกเขาแม้ว่าพวกเขาจะสร้างดังนั้นพวกเขาจะถูกบล็อก ดังนั้นโดยทั่วไปฉันจะขยายการปฏิเสธสิ่งใดก็ตามที่ไม่ผ่านการตรวจสอบคุณภาพขั้นต่ำโดยเลือกสมดุลความต้องการที่ขัดแย้งกัน 2 รายการ: สูงที่สุดเท่าที่จะทำได้เพื่อเพิ่มจำนวน devs ที่ได้รับการป้องกันจากการบล็อกและต่ำที่สุดเท่าที่เป็นไปได้ ไม่ทำให้กระบวนการช้าลงมากเกินไป
Dan Cornilescu

ตัวอย่างนี้อาจเป็นรูปแบบคำขอดึงที่คุณสามารถกำหนดข้อ จำกัด บางอย่างเกี่ยวกับว่าคำขอดึงสามารถรวมหรือไม่ ตัวอย่างเช่นเรา (บริษัท ของฉัน) ใช้เซิร์ฟเวอร์ Atlassian Bitbucket และมีตัวเลือกที่จะต้องมีการอนุมัติอย่างน้อย N จำนวนและจำนวน X ของการส่งผ่านการสร้างสำหรับสาขาที่กำหนดก่อนที่จะอนุญาตให้ดึงคำขอเพื่อรวมเข้าด้วยกัน มันไม่ได้ปฏิเสธเลย แต่ป้องกันการผสานโดยไม่ตั้งใจเมื่อการทดสอบล้มเหลวหรือดวงตาอื่นยังไม่เห็นรหัส
Andy Shinn

@AndyShinn: ใช่ฉันพบว่ามีประโยชน์มาก —GitHub ยังมีสาขาที่ได้รับการคุ้มครองและตรวจสอบคำขอดึงซึ่งมักเป็นประโยชน์
Aurora0001

1
อาร์กิวเมนต์หนึ่งสำหรับการอนุญาตให้รหัสที่ใช้งานไม่ได้ในสาขาคุณลักษณะคืออนุญาตให้ devs ส่งรหัสที่ทำงานกับ repo แม้ว่าจะยังไม่พร้อมก็ตาม สิ่งนี้มีประโยชน์สำหรับการแชร์รหัสกับคนอื่น ๆ สำหรับการรีวิวโค้ด / สถาปัตยกรรมก่อนที่สิ่งต่าง ๆ พร้อมที่จะไปช่วยแก้จุดบกพร่องหรือสำหรับคนที่กำลังลาพักร้อนเพื่อทำงานที่คนอื่นสามารถเข้าไปได้ สำหรับสาขาคุณลักษณะฉันจะใส่เฉพาะสิ่งที่เป็น linters และเป็น hooks ล่วงหน้าก่อน
bradym

2

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

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

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


"ถ้าสาขาทันสมัยกับต้นน้ำ (ซึ่ง PR กำลังรวมอยู่) และการทดสอบผ่านมันจะยังคงผ่านไปหลังจากการผสาน" - ทำไม? การรวมเป็นความไม่ต่อเนื่องทำให้เกิดสิ่งแปลกปลอม เช่นเดียวกับข้อขัดแย้งรหัสอาจไม่ได้สร้างจนกว่าจะได้รับการแก้ไข คุณต้องทำการทดสอบและยืนยันว่าพวกเขาผ่านการรวมสาขาใด ๆ ฉันจะบอกว่าสำหรับการส่งต่อที่รวดเร็วถ้าคุณต้องการเล่นอย่างปลอดภัย ดูapartsw.com/insights/2016/11/16/…
Dan Cornilescu

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

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

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

ประเด็นของฉันคือไม่ใช่เครื่องมือ CI ที่ให้ความคุ้มครองคุณโดยการเขียนการทดสอบ เครื่องมือ CI ไม่สามารถให้การรับประกันใด ๆ นอกเหนือจากการทดสอบที่คุณให้ไว้
Adrian

1

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


แต่ Reitveld ดูเหมือนจะเป็นเครื่องมือตรวจสอบรหัสการทำงานร่วมกันไม่ใช่เครื่องมือ CI ฉันจะทำอะไรบางอย่างหายไปหรือไม่ นี่คือสิ่งที่ฉันดู: github.com/rietveld-codereview/rietveld
Dan Cornilescu

Zuul ดูเหมือนจะเกี่ยวข้องจริง ๆ ฉันจะศึกษามันให้ละเอียด
Dan Cornilescu

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

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

1

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


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

0

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

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

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

เครื่องมือนี้ได้รับการออกแบบมาให้ปรับขนาดได้อย่างง่ายดาย - สามารถรักษาอัตราการเปลี่ยนแปลงของผู้สมัครที่เข้ามาได้อย่างรวดเร็วและสนับสนุนนักพัฒนา 100s / 1000s ที่ทำงานในสาขาการรวมกลุ่มเดียวกัน

คำเตือน:ฉันเป็นผู้เขียนเครื่องมือและเป็นผู้ก่อตั้ง บริษัท ที่เสนอให้ ขอโทษสำหรับโฆษณา


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

ฉันได้ถามคำถามเกี่ยวกับ meta ว่าอนุญาตหรือไม่: meta.devops.stackexchange.com/q/59
THelper

SnapCI ก็ทำเช่นนี้เช่นกัน ฉีก.
paul_h

@paul_h เว้นแต่ว่าฉันจะพลาดอะไรบางอย่างของ SnapCI และการทดแทน GoCD ที่แนะนำนั้นขึ้นอยู่กับการตรวจสอบภายหลังการโพสต์ ยกเว้นอาจจะเป็นสำหรับการตรวจสอบการประชาสัมพันธ์ แต่ถ้าการตรวจสอบเหล่านี้จะต่อเนื่องกันอย่างสมบูรณ์พวกเขาสามารถลดอัตราการเกิดการถดถอย แต่ไม่ได้กำจัดพวกเขาอย่างสมบูรณ์
Dan Cornilescu

แดนไม่หยั่งเสียงไม่เกี่ยวเบ็ด และไปยังสาขาประชาสัมพันธ์สั้น ๆ ที่ยังไม่ถูกรวมเข้ากับลำตัว / ตัวหลัก - trunkbaseddevelopment.com/game-changers/…
paul_h
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.