วิธีหลีกเลี่ยงความไม่แน่นอนที่เกิดจากการรวมอย่างต่อเนื่องในสภาพแวดล้อมการทดสอบ

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

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

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

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

ดังนั้นคุณจะทำอย่างไร (จะกำหนดค่าสิ่งต่าง ๆ ได้อย่างไร) เพื่อหลีกเลี่ยงสถานการณ์ (ที่น่าผิดหวัง)?

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

บริบทบางอย่างที่จะเริ่มต้น:

• เรามี 7 สภาพแวดล้อมในการโฮสต์แอปพลิเคชั่นประมาณ 80 รายการโดยส่วนใหญ่จะพึ่งพาซึ่งกันและกันผ่านเว็บเซอร์วิสหรือตารางที่ใช้ร่วมกันบน db2-iSeries
• ไม่ว่าดีหรือไม่ดี iSeries เป็นระบบฐานข้อมูลอ้างอิงของเรา
• ประเด็นสุดท้ายนี้ทำให้ความคิดใด ๆ ที่ทำให้แอพพลิเคชั่นนั้นไม่ขึ้นอยู่กับสภาพแวดล้อมที่แยกจากกันเนื่องจากการเรียกใช้ AS400 สำหรับแต่ละค่าใช้จ่ายสูงเกินไปและเราจะไม่ต้องใช้ฮาร์ดแวร์ในการทำงาน

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

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

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

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

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

IMHO คุณไม่ควรใช้การทดสอบดังกล่าวในวัตถุประสงค์การรับรอง CI / CD เนื่องจากจะทำให้กระบวนการรับรองของคุณเป็นโมฆะอย่างมีประสิทธิภาพ (อย่างน้อยก็ในพื้นที่นั้น) การกล่าวว่าซอฟต์แวร์ผ่านการทดสอบ X โดยไม่ต้องดำเนินการทดสอบ X สำหรับซอฟต์แวร์ทุกเวอร์ชันที่ส่งมอบหรือไม่มีความมั่นใจว่าpassผลที่ได้รับนั้นไม่ได้เกิดจากอุบัติเหตุ ฟิล์มเนกาทีฟปลอมไม่ใช่ความน่าเชื่อถือ แต่ยังไม่พึงประสงค์เนื่องจากเสียง "ไม่จำเป็น" ที่พวกเขาสร้างขึ้น

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

หากคุณวางแผนที่จะจัดการกับปัญหาคุณควรพัฒนากรณีทดสอบอัตโนมัติที่เชื่อถือได้สำหรับการทำซ้ำปัญหา สิ่งที่คุณจะใช้ในการพัฒนาแก้ไขและยืนยันประสิทธิผล (ผลการทดสอบควรเปลี่ยนจาก FAIL เป็น PASS) คุณสามารถ (ควร?) วางกล่องทดสอบนี้ไว้ในกระบวนการรับรอง CI / CD ของคุณเพื่อป้องกันการเกิดขึ้นอีกในอนาคตหากต้องการ - เพื่อเพิ่มระดับคุณภาพการปล่อยซอฟต์แวร์โดยรวมของคุณ

วิธีการปกติคือการสร้างสภาพแวดล้อมที่แตกต่างกัน:

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

PREPROD / QA - นี่คือสถานที่ "เล่น" ทีม QA / ทดสอบ / การตรวจสอบจะทำการทดสอบ สภาพแวดล้อมนี้มักจะหยุดในระหว่างการทดสอบ การรวม CI เข้ากับสภาพแวดล้อมนี้เป็นเพียงการจัดหาผลิตภัณฑ์รุ่นใหม่การกำหนดค่า ฯลฯ

การผลิต - มันจำเป็นต้องอธิบาย :)

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

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

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

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