อีเมลใช้แล้วทิ้งใน CI/CD: ทดสอบโฟลว์ OTP และการลงทะเบียนบน GitHub, GitLab และ CircleCI

ประเด็นสำคัญสำหรับทีม DevOps ที่มีงานล้นมือ

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

• ไปป์ไลน์ CI/CD มักต้องจัดการโฟลว์อีเมล เช่น การสมัครบัญชี การยืนยัน OTP การรีเซ็ตรหัสผ่าน และการแจ้งเตือนการเรียกเก็บเงิน ซึ่งไม่สามารถทดสอบได้อย่างน่าเชื่อถือด้วยกล่องจดหมายจริงของผู้ใช้ที่ใช้ร่วมกัน
• กลยุทธ์กล่องจดหมายแบบใช้แล้วทิ้งที่เป็นระบบจะจับคู่วงจรชีวิตของกล่องจดหมายกับวงจรชีวิตของไปป์ไลน์ ทำให้การทดสอบมีผลลัพธ์แน่นอน พร้อมปกป้องผู้ใช้จริงและกล่องจดหมายของพนักงาน
• GitHub Actions, GitLab CI และ CircleCI ล้วนสามารถสร้าง ส่งต่อ และใช้งานที่อยู่อีเมลชั่วคราวผ่านตัวแปรสภาพแวดล้อมหรือเอาต์พุตของงานได้
• ความปลอดภัยเกิดจากกฎที่เข้มงวด: ห้ามบันทึก OTP หรือ token ของกล่องจดหมาย กำหนดระยะเวลาเก็บรักษาให้สั้น และอนุญาตให้ใช้กล่องจดหมายซ้ำได้เฉพาะเมื่อระดับความเสี่ยงเอื้อเท่านั้น
• ด้วยการวัดผลพื้นฐาน คุณสามารถติดตามเวลาส่ง OTP รูปแบบความล้มเหลว และปัญหาของผู้ให้บริการ ทำให้การทดสอบที่ใช้อีเมลวัดผลและคาดการณ์ได้

ทำให้ CI/CD ปลอดภัยสำหรับการใช้อีเมล

อีเมลเป็นหนึ่งในส่วนที่ซับซ้อนที่สุดของการทดสอบแบบ end-to-end และ CI/CD จะขยายปัญหาทุกอย่างเกี่ยวกับกล่องจดหมายที่คุณมองข้ามในสภาพแวดล้อม staging

อีเมลปรากฏที่ใดในการทดสอบอัตโนมัติ

แอปพลิเคชันสมัยใหม่ส่วนใหญ่ส่งอีเมลธุรกรรมอย่างน้อยสองสามฉบับระหว่างเส้นทางการใช้งานตามปกติ การทดสอบอัตโนมัติในไปป์ไลน์ CI/CD ของคุณมักต้องผ่านโฟลว์ต่าง ๆ เช่น การสมัครบัญชี การยืนยันด้วย OTP หรือลิงก์มหัศจรรย์ การรีเซ็ตรหัสผ่าน การยืนยันการเปลี่ยนที่อยู่อีเมล การแจ้งเตือนการเรียกเก็บเงิน และการแจ้งเตือนการใช้งาน

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

เหตุใดกล่องจดหมายจริงจึงไม่รองรับการขยายงานใน QA

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

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

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

กล่องจดหมายแบบใช้แล้วทิ้งเข้ากับ CI/CD ได้อย่างไร

แนวคิดหลักเรียบง่าย: การรัน CI/CD หรือชุดทดสอบแต่ละครั้งจะได้รับที่อยู่อีเมลใช้แล้วทิ้งของตัวเอง ซึ่งผูกไว้กับผู้ใช้จำลองและข้อมูลอายุสั้นเท่านั้น แอปพลิเคชันที่กำลังทดสอบจะส่ง OTP ลิงก์ยืนยัน และการแจ้งเตือนไปยังที่อยู่นั้น จากนั้นไปป์ไลน์จะดึงเนื้อหาอีเมลผ่าน API หรือปลายทาง HTTP แบบง่าย แยกข้อมูลที่ต้องใช้ แล้วทิ้งกล่องจดหมายนั้นไป

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

ออกแบบกลยุทธ์กล่องจดหมายที่เป็นระบบ

ก่อนเริ่มเขียน YAML ให้ตัดสินใจก่อนว่าต้องใช้กล่องจดหมายกี่กล่อง แต่ละกล่องมีอายุการใช้งานนานเท่าใด และความเสี่ยงใดบ้างที่คุณไม่ยอมรับ

กล่องจดหมายทดสอบแยกต่อบิลด์เทียบกับกล่องจดหมายทดสอบที่ใช้ร่วมกัน

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

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

การจับคู่กล่องจดหมายเข้ากับสถานการณ์ทดสอบ

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

ใช้หลักการตั้งชื่อที่ระบุทั้งสถานการณ์และสภาพแวดล้อม เช่น signup-us-east-@example-temp.com หรือ password-reset-staging-@example-temp.com วิธีนี้ช่วยให้ติดตามย้อนกลับไปยังการทดสอบที่เจาะจงได้ง่ายขึ้นเมื่อเกิดข้อผิดพลาด

เมื่ออีเมลชั่วคราวไม่ใช่เครื่องมือที่เหมาะสม

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

การเลือกผู้ให้บริการอีเมลใช้แล้วทิ้งสำหรับ CI/CD

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

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

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

เชื่อมต่ออีเมลชั่วคราวเข้ากับ GitHub Actions

GitHub Actions ช่วยให้เพิ่มขั้นตอนก่อนการทดสอบเพื่อสร้างกล่องจดหมายอีเมลใช้แล้วทิ้ง และส่งข้อมูลดังกล่าวให้การทดสอบแบบผสานรวมผ่านตัวแปรสภาพแวดล้อมได้ง่าย

รูปแบบ: สร้างกล่องจดหมายเข้าก่อนงานทดสอบ

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

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

การใช้ข้อความอีเมลยืนยันในขั้นตอนการทดสอบ

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

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

การล้างข้อมูลหลังการรันเวิร์กโฟลว์แต่ละครั้ง

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

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

เชื่อมต่ออีเมลชั่วคราวเข้ากับ GitLab CI/CD

Pipeline ของ GitLab สามารถกำหนดให้การสร้างกล่องจดหมายอีเมลใช้แล้วทิ้งเป็น stage โดยเฉพาะ และส่งต่อที่อยู่อีเมลไปยังงานถัดไปโดยไม่เปิดเผยข้อมูลลับ

การออกแบบขั้นตอนในไปป์ไลน์ที่รองรับอีเมล

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

การส่งรายละเอียดกล่องขาเข้าระหว่างงาน

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

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

การแก้ไขข้อบกพร่องของการทดสอบที่ใช้อีเมลซึ่งไม่เสถียร

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

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

เชื่อมต่ออีเมลชั่วคราวเข้ากับ CircleCI

งานและ orb ของ CircleCI สามารถครอบคลุมรูปแบบทั้งหมดตั้งแต่ "สร้างกล่องขาเข้า → รออีเมล → ดึง token" เพื่อให้ทีมต่าง ๆ นำไปใช้ซ้ำได้อย่างปลอดภัย

รูปแบบระดับงานสำหรับการทดสอบอีเมล

ใน CircleCI รูปแบบทั่วไปคือมีขั้นตอนก่อนเริ่มงานที่เรียกใช้ผู้ให้บริการอีเมลชั่วคราว บันทึกที่อยู่ที่สร้างขึ้นไว้ในตัวแปรสภาพแวดล้อม แล้วจึงเรียกใช้การทดสอบแบบ end-to-end โค้ดทดสอบจะทำงานเช่นเดียวกับใน GitHub Actions หรือ GitLab CI โดยรออีเมล ดึง OTP หรือลิงก์ แล้วดำเนินสถานการณ์ทดสอบต่อ

การใช้ orb และคำสั่งที่นำกลับมาใช้ใหม่ได้

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

การปรับขนาดการทดสอบอีเมลในงานแบบขนาน

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

ลดความเสี่ยงในไปป์ไลน์การทดสอบ

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

เก็บความลับและ OTP ออกจากบันทึก

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

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

การจัดการ token และกล่องขาเข้าที่นำกลับมาใช้ใหม่ได้อย่างปลอดภัย

ผู้ให้บริการบางรายอนุญาตให้คุณกลับไปยังที่อยู่เดิมในภายหลังโดยใช้ token สำหรับการกู้คืน — Tmailor เรียกสิ่งนี้ว่า access token — ซึ่งมีประโยชน์สำหรับสภาพแวดล้อม QA และ UAT ที่ใช้งานเป็นเวลานาน ควรเข้าใจให้ชัดเจนว่ามันคืออะไร เพราะทีมต่าง ๆ มักเข้าใจผิดอยู่เสมอ มันคือ คีย์กู้คืน ไม่ใช่รหัสผ่านและไม่ใช่ตัวล็อก: ช่วยให้คุณกลับไปยังที่อยู่เดิมได้ แต่ไม่ได้ป้องกันไม่ให้ผู้อื่นเข้าถึง และหากคุณทำหาย ก็ไม่มีใครกู้คืนให้คุณได้ ดังนั้นควรจัดเก็บไว้ในตู้นิรภัยสำหรับความลับเดียวกับ API keys ของคุณ โดยถือว่าผู้ที่มีคีย์นี้สามารถเข้าถึงกล่องขาเข้านั้นได้ ไม่ใช่เก็บเพราะเข้าใจผิดว่าคีย์นี้ช่วยปกป้องกล่องขาเข้า และโปรดทราบข้อจำกัดด้วยว่า คีย์นี้กู้คืนได้เฉพาะ ที่อยู่ ไม่ใช่จดหมาย ข้อความที่หมดอายุไปแล้วจะหายไป ดังนั้นกล่องจดหมายที่นำกลับมาใช้ใหม่จึงไม่ใช่ที่เก็บถาวร

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

การปฏิบัติตามข้อกำหนดและการเก็บรักษาข้อมูลสำหรับข้อมูลการทดสอบ

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

จัดทำนโยบายฉบับกระชับที่อธิบายว่าเหตุใดจึงใช้อีเมลใช้แล้วทิ้งใน CI/CD จัดเก็บข้อมูลใดไว้ที่ไหน และเก็บไว้นานเท่าใด วิธีนี้จะทำให้การพูดคุยกับทีมรักษาความปลอดภัย ความเสี่ยง และการปฏิบัติตามข้อกำหนดง่ายขึ้นมาก

วัดผลและปรับแต่งการทดสอบอีเมล

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

ติดตามเวลาส่ง OTP และอัตราความสำเร็จ

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

แนวทางป้องกันเมื่อโฟลว์อีเมลล้มเหลว

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

ปรับปรุงผู้ให้บริการ โดเมน และรูปแบบอย่างต่อเนื่อง

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

แหล่งข้อมูลและการอ่านเพิ่มเติม

พฤติกรรมของแพลตฟอร์มอาจเปลี่ยนแปลงได้ ดังนั้นให้ถือว่าเอกสารของผู้ให้บริการเป็นแหล่งอ้างอิงหลักสำหรับกลไกเฉพาะต่าง ๆ เช่น เอกสารของ GitHub เกี่ยวกับเอาต์พุตของงานและความลับที่ปกปิด เอกสารของ GitLab เกี่ยวกับตัวแปรที่ปกปิดและไฟล์ที่ปลอดภัย และเอกสารของ CircleCI เกี่ยวกับ orbs และการทำงานแบบขนาน สำหรับเรื่องอีเมล บทความที่เกี่ยวข้องในเว็บไซต์นี้จะลงรายละเอียดมากกว่าคู่มือนี้: อะไรใช้ได้ผลและล้มเหลวกับ OTP การหมุนเวียนโดเมนและความน่าเชื่อถือของ OTP, รายการตรวจสอบความเสี่ยง OTP สําหรับ QA

สรุปสาระสำคัญ

อีเมลใช้แล้วทิ้งไม่ได้เป็นเพียงฟีเจอร์อำนวยความสะดวกสำหรับแบบฟอร์มสมัครใช้งานเท่านั้น หากใช้อย่างรอบคอบ อีเมลนี้จะกลายเป็นองค์ประกอบสำคัญที่ทรงพลังภายในไปป์ไลน์ CI/CD ของคุณ ด้วยการสร้างกล่องจดหมายอายุสั้น เชื่อมต่อเข้ากับ GitHub Actions, GitLab CI และ CircleCI และบังคับใช้กฎที่เข้มงวดเกี่ยวกับข้อมูลลับและการบันทึกข้อมูล คุณจะสามารถทดสอบโฟลว์อีเมลสำคัญได้โดยไม่ต้องใช้กล่องจดหมายจริงในกระบวนการ

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