อีเมลใช้แล้วทิ้งใน CI/CD: ทดสอบ OTP และขั้นตอนการสมัครสมาชิกบน GitHub, GitLab, CircleCI

ข้อคิดสำคัญสำหรับทีม DevOps ที่ยุ่งมาก

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

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

ทำให้ CI/CD ปลอดภัยต่ออีเมล

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

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

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

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

ทำไมกล่องจดหมายจริงจึงขยาย規模ไม่ได้ใน QA

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

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

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

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

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

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

ออกแบบกลยุทธ์กล่องจดหมายที่รัดกุม

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

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

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

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

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

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

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

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

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

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

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

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

การเข้าถึงเป็นอีกเรื่องที่ต้องตั้งหลักตั้งแต่เนิ่นๆ Tmailor ตอนนี้เผยแพร่ API Temp Mail สาธารณะที่มีเอกสารกำกับ (REST, JSON) ซึ่งตัวรันทดสอบสามารถเรียกใช้ได้โดยตรง: สร้างที่อยู่แบบรับอย่างเดียว แสดงรายการและอ่านข้อความของที่อยู่นั้น และดึงรหัสใช้ครั้งเดียวและลิงก์ที่ API สกัดออกมาจากแต่ละข้อความ (เท่าที่ทำได้) มี SDK อย่างเป็นทางการสำหรับ Python, Node.js และ PHP และแผนฟรีต้องเพิ่ม IP ของเซิร์ฟเวอร์หนึ่งรายการในรายการที่อนุญาต ดังนั้นควรวางแผนว่าคำขอของตัวรันทดสอบจะมาจากที่ใด ใช้มันเพื่อทดสอบขั้นตอนการสมัคร การยืนยัน และการรีเซ็ตรหัสผ่านของคุณเอง ไม่ว่าอย่างไรก็ให้ถือว่าโทเค็นกู้คืนของผู้ให้บริการรายใดก็ตามและคีย์ API ใดๆ เป็นความลับ

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

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

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

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

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

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

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

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

การทำความสะอาดหลังการรันเวิร์กโฟลว์แต่ละครั้ง

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

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

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

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

การออกแบบขั้นตอน pipeline ที่คำนึงถึงอีเมล

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

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

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

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

การดีบักการทดสอบอีเมลที่ล้มเหลวไม่สม่ำเสมอ

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

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

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

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

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

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

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

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

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

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

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

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

การเก็บข้อมูลลับและ OTP ให้พ้นจาก log

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

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

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

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

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

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

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

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

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

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

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

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

แนวป้องกันเมื่อกระบวนการอีเมลล้มเหลว

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

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

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

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

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

บทสรุป

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

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