บลู-กรีน ดีพลอยเมนต์สำหรับ API: ทดสอบอย่างไรก่อนสลับไปใช้งานจริง

การปรับใช้แบบ Blue-green สัญญาว่าจะปล่อยเวอร์ชันใหม่โดยไม่มีการหยุดทำงาน: คุณจะสร้างสำเนาบริการชุดใหม่ขึ้นมา ส่งทราฟฟิกบางส่วนไปทดสอบ และสลับใช้งานจริงเมื่อเห็นว่าระบบทำงานเป็นปกติ ปัญหาคือคำว่า “ปกติ” การตรวจสอบสถานะของโหลดบาลานเซอร์มักจะพิงไปยังเอนด์พอยต์หนึ่งและรอ 200 สิ่งนี้บอกคุณว่ากระบวนการทำงานอยู่ แต่ไม่ได้บอกอะไรเลยว่าบิลด์ใหม่ของคุณส่งคืน JSON ที่ถูกต้องหรือไม่, ปฏิบัติตามข้อตกลงเดิมหรือไม่ หรือยังคงตรวจสอบโทเค็นแบบเดียวกับเวอร์ชันเก่าหรือไม่ ดังนั้นคุณจึงสลับใช้งาน และผู้ใช้จริงคนแรกก็พบข้อบกพร่องที่การตรวจสอบสถานะของคุณมองไม่เห็น

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

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

TL;DR (สรุป)

การปรับใช้แบบ Blue-green รันสภาพแวดล้อมการผลิตที่เหมือนกันสองชุดและสลับเราเตอร์ระหว่างกัน ก่อนที่คุณจะสลับทราฟฟิกจากสีน้ำเงิน (blue - ที่ใช้งานจริง) ไปยังสีเขียว (green - เวอร์ชันใหม่) ให้รันชุดการทดสอบ API ทั้งหมดของคุณกับสภาพแวดล้อมสีเขียวโดยตรง กำหนดให้การสลับใช้งานต้องผ่านผลลัพธ์ของชุดทดสอบที่ทำงานกับบิลด์สีเขียว ด้วย Apidog CLI ให้กำหนดเป้าหมายสถานการณ์การทดสอบเดียวกันไปยัง URL พื้นฐานสีเขียวในไปป์ไลน์ของคุณ หากมีการยืนยันใดๆ ล้มเหลว ให้ยกเลิกการปรับใช้ และหลังจากนั้นค่อยสลับเราเตอร์ การตรวจสอบสถานะยืนยันว่ากระบวนการทำงานอยู่ ส่วนการทดสอบ API ยืนยันว่าข้อตกลงยังคงใช้ได้

การปรับใช้แบบ Blue-green คืออะไรกันแน่

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

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

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

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

ทำไมการตรวจสอบสถานะจึงไม่ใช่การทดสอบ

นี่คือช่องว่างที่ทำให้ทีมต่างๆ ต้องเผชิญปัญหา การตรวจสอบสถานะทั่วไปมีลักษณะดังนี้:

# Load balancer health probe
GET /health -> 200 OK -> mark target healthy

เอนด์พอยต์นั้นมักจะส่งคืน {"status":"ok"} ที่ถูกฮาร์ดโค้ดไว้ ไม่ได้แตะฐานข้อมูลของคุณ ไม่ได้ทดสอบการตรวจสอบสิทธิ์ ไม่ได้ทำให้ทรัพยากรจริงเป็นอนุกรม บิลด์สามารถผ่านการตรวจสอบนี้ได้ในขณะที่เอนด์พอยต์ทางธุรกิจทุกตัวส่งคืน 500, เพย์โหลดที่ผิดรูป หรือสคีมาของเมื่อวาน

พิจารณารูปแบบความล้มเหลวที่การพิง /health จะยินดีผ่านไป:

การย้ายข้อมูลที่ไม่ได้ทำงาน ดังนั้น GET /orders/{id} จึงเกิดข้อผิดพลาดเนื่องจากคอลัมน์หายไป
ฟิลด์ JSON ที่เปลี่ยนชื่อ (user_id กลายเป็น userId) ซึ่งทำให้ผู้บริโภคปลายน้ำทุกรายใช้งานไม่ได้
การเปลี่ยนแปลงการตรวจสอบสิทธิ์ที่ตอนนี้ปฏิเสธโทเค็นที่แอปมือถือยังคงออกอยู่
การอัปเดตเวอร์ชันของส่วนเสริมที่เปลี่ยนรูปแบบวันที่จาก ISO 8601 เป็น Unix timestamp
ส่วนหัวที่จำเป็นใหม่ที่ส่งคืน 400 สำหรับไคลเอ็นต์ใดๆ ที่ไม่ได้ส่ง

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

เวิร์กโฟลว์การทดสอบแบบ Blue-green แบบครบวงจร

นี่คือลำดับที่เรากำลังสร้างขึ้น ขั้นตอนใหม่คือ "ทดสอบสภาพแวดล้อมสีเขียว" และอยู่ระหว่างการปรับใช้และการสลับใช้งาน

ปรับใช้กับสภาพแวดล้อมสีเขียว (Deploy to green) พุชบิลด์ใหม่ไปยังสภาพแวดล้อมที่ไม่ได้ใช้งาน มันจะสามารถเข้าถึงได้ที่อยู่ภายใน เช่น https://green.internal.example.com แต่ยังไม่มีทราฟฟิกสาธารณะเข้าถึง
ทดสอบแบบ Smoke test กับสภาพแวดล้อมสีเขียว (Smoke test green) เรียกใช้ชุดย่อยของการร้องขอที่สำคัญอย่างรวดเร็วกับสภาพแวดล้อมสีเขียว การเข้าสู่ระบบ, ดึงทรัพยากรหลัก, สร้างหนึ่งรายการ หากมีรายการใดล้มเหลว ให้หยุดที่นี่ Blue ยังคงให้บริการผู้ใช้และไม่ได้รับผลกระทบ
รันชุดทดสอบทั้งหมดกับสภาพแวดล้อมสีเขียว (Run the full suite against green) ดำเนินการสถานการณ์การทดสอบ API ทั้งหมดของคุณ (เส้นทางที่สำเร็จ, กรณีข้อผิดพลาด, กระบวนการตรวจสอบสิทธิ์, การยืนยันสคีมา) โดยกำหนดเป้าหมายไปยัง URL พื้นฐานของสภาพแวดล้อมสีเขียว
ควบคุมการสลับใช้งาน (Gate the cutover) หากชุดทดสอบผ่าน ให้ดำเนินการต่อ หากมีรายการใดล้มเหลว ไปป์ไลน์จะหยุดทำงานและสภาพแวดล้อมสีเขียวจะถูกลบทิ้งหรือปล่อยไว้เพื่อตรวจสอบ การผลิตไม่ได้รับผลกระทบ
สลับสวิตช์ (Flip the switch) กำหนดเราเตอร์ (โหลดบาลานเซอร์, DNS หรือตัวเลือกบริการ) ใหม่จาก blue ไปยัง green
ตรวจสอบในการผลิต (Verify in production) เรียกใช้ smoke test เดียวกันกับ URL ที่ใช้งานจริงหลังจากการสลับใช้งานเพื่อยืนยันว่าการสลับมีผลอย่างสะอาดหมดจด
รักษาสภาพแวดล้อมสีน้ำเงินให้อบอุ่น (Keep blue warm) รักษาสภาพแวดล้อมเก่าไว้สำหรับช่วงเวลาการย้อนกลับ หากการตรวจสอบหลังการสลับใช้งานมีปัญหา ให้สลับกลับทันที

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

การสร้างสถานการณ์การทดสอบใน Apidog

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

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

ชุดเริ่มต้นที่เป็นประโยชน์สำหรับบริการคำสั่งซื้อ:

กระบวนการยืนยันตัวตน (Auth flow): POST /auth/login ด้วยข้อมูลรับรองที่ถูกต้อง, ยืนยัน 200, แยกโทเค็น bearer ไปยังตัวแปร, จากนั้นใช้มันในการร้องขอที่ตามมาทั้งหมด
เส้นทางการอ่าน (Read path): GET /orders ด้วยโทเค็น, ยืนยัน 200, ยืนยันว่าการตอบกลับเป็นอาร์เรย์, ยืนยันว่าแต่ละรายการมี id, status และ total
ทรัพยากรเดี่ยว (Single resource): GET /orders/{id}, ยืนยันว่าสคีมาตรงกับคำนิยาม OpenAPI ของคุณ, ยืนยันว่า total เป็นตัวเลขที่มากกว่าศูนย์
เส้นทางการเขียน (Write path): POST /orders ด้วยเนื้อหาที่ถูกต้อง, ยืนยัน 201, ยืนยันว่า id ที่ส่งคืนไม่ว่างเปล่า, จากนั้น GET id ใหม่นั้นกลับมาเพื่อยืนยันว่ามันถูกบันทึกไว้
กรณีเชิงลบ (Negative cases): GET /orders/{id} ด้วยโทเค็นที่ไม่ถูกต้อง, ยืนยัน 401 POST /orders โดยไม่มีฟิลด์ที่จำเป็น, ยืนยัน 400

คุณสมบัติสองอย่างที่สำคัญที่สุดในการตรวจจับความล้มเหลวที่การตรวจสอบสถานะพลาดไป ประการแรก การยืนยันสคีมา (schema assertions): Apidog สามารถตรวจสอบการตอบกลับเทียบกับ JSON Schema หรือคำนิยาม OpenAPI สำหรับเอนด์พอยต์นั้นได้ ดังนั้นฟิลด์ที่เปลี่ยนชื่อหรือเปลี่ยนประเภทจะทำให้การทดสอบล้มเหลวแทนที่จะหลุดรอดไปสู่การผลิต ประการที่สอง การยืนยันการตอบกลับ (response assertions) บนค่าเฉพาะ, ส่วนหัว และเวลาตอบสนอง เพื่อให้คุณตรวจจับความคลาดเคลื่อนเล็กน้อยได้: การเปลี่ยนแปลงรูปแบบวันที่, ค่า null ในที่ที่คุณคาดหวังตัวเลข, หรือประสิทธิภาพที่ลดลง

การตัดสินใจออกแบบที่สำคัญคือการจัดการสภาพแวดล้อม อย่าฮาร์ดโค้ด https://blue.example.com ลงในคำขอของคุณ กำหนด ตัวแปรสภาพแวดล้อม (environment variable) สำหรับ URL พื้นฐานและอ้างอิงมันทุกที่ในชื่อ {{baseUrl}} ใน Apidog คุณตั้งค่าสภาพแวดล้อม (Production, Green, Local) และสลับตัวที่ใช้งานอยู่ หรือคุณสามารถแทนที่ URL พื้นฐานในขณะรันไทม์จาก CLI นี่คือหลักการจัดการสภาพแวดล้อมและความลับแบบเดียวกับที่ครอบคลุมในคู่มือของเราสำหรับ ไคลเอ็นต์ API ที่มีการจัดการสภาพแวดล้อมและความลับ; การทดสอบของคุณยังคงเหมือนเดิมระหว่าง blue และ green มีเพียงเป้าหมายเท่านั้นที่เปลี่ยนไป

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

การรันชุดทดสอบจากบรรทัดคำสั่ง

แอปเดสก์ท็อปคือที่ที่คุณสร้างและดีบักสถานการณ์ต่างๆ ส่วน CLI คือสิ่งที่รันสถานการณ์เหล่านั้นในไปป์ไลน์ของคุณกับสภาพแวดล้อมสีเขียว ติดตั้งด้วย npm; คุณต้องใช้ Node.js v16 หรือใหม่กว่า:

npm install -g apidog-cli

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

apidog run "https://api.apidog.com/api/v1/api-test/ci-config/<config-id>/detail?token=<token>" \
  -r html,cli \
  --out-file green-readiness

แฟล็ก -r เลือกตัวรายงาน cli พิมพ์ผลลัพธ์ลงในเทอร์มินัลเพื่อให้บันทึกของไปป์ไลน์ของคุณแสดงว่าการยืนยันใดล้มเหลว html เขียนรายงานแบบครบวงจรที่คุณสามารถเก็บเป็น artifacts ของบิลด์สำหรับผู้ที่ตรวจสอบการปรับใช้ นอกจากนี้ยังมีตัวรายงาน JSON เมื่อคุณต้องการป้อนผลลัพธ์ไปยังเครื่องมืออื่น แฟล็ก --out-file ตั้งชื่อเอาต์พุตเพื่อให้แต่ละการรันสามารถติดตามไปยังบิลด์ได้

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

# Test the green (idle) environment before cutover
apidog run "<ci-config-url>" \
  --environment <greenEnvironmentId> \
  -r cli,html \
  --out-file green-pre-switch

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

apidog run --exported-data ./tests/orders-readiness.json \
  --variables ./tests/green.variables.json \
  -r cli

สำหรับการทัวร์ชมตัวรันและตัวเลือกต่างๆ อย่างละเอียดในบริบทของไปป์ไลน์ โปรดดู วิธีการทำให้การทดสอบ API เป็นอัตโนมัติใน CI/CD พฤติกรรมที่สำคัญสำหรับการปรับใช้แบบ blue-green คือรหัสออก (exit code): เมื่อการยืนยันล้มเหลว CLI จะออกด้วยรหัสที่ไม่ใช่ศูนย์ ความจริงข้อเดียวนี้คือสิ่งที่ทำให้คุณสามารถควบคุมการสลับใช้งานได้ รหัสออกที่ไม่ใช่ศูนย์จะหยุดไปป์ไลน์ก่อนที่ขั้นตอนการสลับจะทำงาน

การเชื่อมต่อเข้ากับ GitHub Actions Pipeline

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

name: deploy-blue-green

on:
  push:
    branches: [main]

jobs:
  deploy-green:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy build to green environment
        run: ./scripts/deploy-green.sh
      # green is now reachable at https://green.internal.example.com

  test-green:
    needs: deploy-green
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install Apidog CLI
        run: npm install -g apidog-cli
      - name: Run readiness suite against green
        run: |
          apidog run "${{ secrets.APIDOG_CI_CONFIG_URL }}" \
            --environment "${{ vars.GREEN_ENV_ID }}" \
            -r cli,html \
            --out-file green-readiness
      - name: Archive HTML report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: green-readiness-report
          path: ./green-readiness.html

  switch-traffic:
    needs: test-green        # only runs if test-green passed
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Flip router from blue to green
        run: ./scripts/switch-to-green.sh
      - name: Smoke test production URL post-switch
        run: |
          npm install -g apidog-cli
          apidog run "${{ secrets.APIDOG_SMOKE_CONFIG_URL }}" \
            --environment "${{ vars.PROD_ENV_ID }}" \
            -r cli

ห่วงโซ่การพึ่งพาจะทำการควบคุมให้คุณ switch-traffic ระบุ needs: test-green ดังนั้นหากชุดความพร้อมใช้งานล้มเหลว งานสลับจะไม่เริ่มทำงาน สภาพแวดล้อมสีเขียวจะยังคงไม่ได้ใช้งาน สีน้ำเงินยังคงให้บริการ และไม่มีใครที่อยู่ปลายน้ำได้รับผลกระทบ การใช้ if: always() ในการอัปโหลดอาร์ติแฟกต์หมายความว่าคุณจะได้รับรายงาน HTML แม้ในกรณีที่เกิดความล้มเหลว ซึ่งเป็นช่วงเวลาที่คุณต้องการอ่านรายงานนั้นมากที่สุด

เก็บ URL การกำหนดค่า CI และโทเค็นเป็นความลับของที่เก็บโค้ด (repository secrets) ไม่ใช่วางไว้ในบรรทัดโดยตรง รหัสสภาพแวดล้อมสามารถเก็บเป็นตัวแปรของที่เก็บโค้ดได้เนื่องจากไม่เป็นความลับ หากทีมของคุณทำงานบน GitLab, Jenkins, CircleCI หรือ Azure Pipelines โครงสร้างจะเหมือนกัน: ขั้นตอนการทดสอบที่ออกด้วยรหัสที่ไม่ใช่ศูนย์จะบล็อกขั้นตอนการสลับ คำแนะนำของเราเกี่ยวกับ การทำให้การทดสอบ API เป็นอัตโนมัติใน GitHub Actions ครอบคลุมการตั้งค่าตัวรันโดยละเอียดมากขึ้น และรูปแบบเดียวกันนี้สามารถถ่ายโอนไปยังแพลตฟอร์มใดๆ เหล่านี้ได้

Smoke test ก่อน, Full suite ทีหลัง

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

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

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

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

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

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

ทีมต่างๆ นำ Blue-green มาใช้แต่ก็ยังส่งมอบสิ่งที่เสียหายอยู่บ่อยครั้ง ซึ่งมักจะเป็นหนึ่งในข้อผิดพลาดเหล่านี้:

ทดสอบสภาพแวดล้อมสีน้ำเงินแทนที่จะเป็นสีเขียว หากชุดทดสอบของคุณกำหนดเป้าหมายไปยัง URL ที่ใช้งานจริง คุณกำลังทดสอบเวอร์ชันที่อยู่ในโปรดักชันอยู่แล้ว ไม่ใช่เวอร์ชันที่คุณกำลังจะปล่อยออกมา กำหนดเป้าหมายไปยัง URL พื้นฐานสีเขียวอย่างชัดเจนก่อนการสลับใช้งานเสมอ
ตรวจสอบเฉพาะรหัสสถานะเท่านั้น รหัส 200 ที่มีเนื้อหาผิดก็ยังคงเป็นการตอบกลับที่เสียหาย ยืนยันรูปแบบเพย์โหลดและค่าหลัก ไม่ใช่แค่สถานะ HTTP การยืนยันสคีมาคือสิ่งที่ตรวจจับการเปลี่ยนชื่อฟิลด์และการเปลี่ยนประเภท
ข้ามกรณีเชิงลบ บิลด์ที่ส่งคืน 200 สำหรับโทเค็นที่ไม่ถูกต้องคือข้อบกพร่องด้านความปลอดภัยที่การทดสอบแบบ happy-path จะไม่สามารถตรวจจับได้ รวมกรณี 401, 403 และ 400 ไว้ในการควบคุม
ไม่มีวินัยในการย้อนกลับ จุดแข็งของ Blue-green คือการย้อนกลับได้ทันที แต่ก็ต่อเมื่อคุณรักษาสภาพแวดล้อมสีน้ำเงินให้อบอุ่น อย่าลบมันทิ้งทันทีที่สภาพแวดล้อมสีเขียวเริ่มทำงานจริง ให้เก็บมันไว้ตลอดช่วงเวลาการตรวจสอบของคุณ
URL ที่ฮาร์ดโค้ดไว้ในคำขอทดสอบ ทันทีที่ URL พื้นฐานถูกฝังอยู่ในคำขอ คุณก็สูญเสียความสามารถในการรันชุดทดสอบเดียวกันกับสภาพแวดล้อมสีเขียวและสีน้ำเงิน ใช้ตัวแปรสภาพแวดล้อมสำหรับโฮสต์ทุกครั้ง
การคิดว่าการตรวจสอบสถานะคือการควบคุม บทความทั้งหมดนี้สรุปได้ในประโยคเดียว การตรวจสอบบอกโหลดบาลานเซอร์ว่ามีกระบวนการทำงานอยู่ การทดสอบ API ของคุณบอกว่าข้อตกลงยังคงใช้ได้

Blue-green เทียบกับ Canary: การทดสอบเข้ากันได้อย่างไร

Blue-green ไม่ใช่กลยุทธ์เดียวที่ไม่มีการหยุดทำงาน และวิธีการทดสอบจะเปลี่ยนไปตามแต่ละกลยุทธ์

กลยุทธ์	การเคลื่อนย้ายทราฟฟิก	การทดสอบ API เข้ากันได้อย่างไร
Blue-green	ทั้งหมดในคราวเดียว, จาก blue ไป green	ชุดทดสอบเต็มรูปแบบกับ green ก่อน การสลับ; การควบคุมจะอยู่ก่อนการสลับ
Canary	ค่อยๆ, เปอร์เซ็นต์เล็กน้อยไปยังเวอร์ชันใหม่	การยืนยันอย่างต่อเนื่องกับส่วน canary; โปรโมทเมื่อเมตริกสะอาด
Rolling	ทีละอินสแตนซ์, ในตำแหน่งเดิม	Smoke checks ทีละอินสแตนซ์; ควบคุมได้ยากกว่าเพราะการ Rollout เริ่มต้นไปแล้ว
Recreate	หยุดตัวเก่า, เริ่มตัวใหม่ (มีการหยุดทำงาน)	ชุดทดสอบจะทำงานในช่วงเวลาที่หยุดทำงาน; การหยุดทำงานคือสิ่งแลกเปลี่ยน

Blue-green ให้การควบคุมที่สะอาดที่สุดในสี่วิธีเพราะสภาพแวดล้อมสีเขียวได้รับการปรับใช้และแยกส่วนอย่างสมบูรณ์เมื่อคุณทดสอบ คุณได้รับสำเนาการผลิตที่สมบูรณ์เพื่อตรวจสอบ โดยไม่มีการเปิดเผยต่อผู้ใช้ และการสลับแบบอะตอมมิกเพียงครั้งเดียว Canary แลกกับการควบคุมที่สะอาดนั้นกับการเปิดเผยทีละน้อยและพึ่งพาการตรวจสอบแบบสด (live monitoring) มากขึ้น สำหรับบริการส่วนใหญ่ที่ขับเคลื่อนด้วย API การใช้ blue-green ร่วมกับชุดทดสอบก่อนการสลับเป็นวิธีที่ง่ายที่สุดในการได้รับความมั่นใจสูงโดยไม่มีช่วงเวลาบำรุงรักษา

รูปแบบการใช้งานจริง

ทีมฟินเทคที่รัน Payments API ใช้ blue-green สำหรับทุกการเผยแพร่ เพราะการปรับใช้ที่ผิดพลาดไม่ใช่แค่บั๊กด้านรูปลักษณ์ แต่เป็นการทำธุรกรรมที่ล้มเหลว การควบคุมของพวกเขาคือชุดทดสอบ 40 สถานการณ์กับสภาพแวดล้อมสีเขียว ครอบคลุมการตรวจสอบสิทธิ์, กุญแจ idempotency, การปัดเศษสกุลเงิน และลายเซ็น webhook การรันทั้งหมดใช้เวลาประมาณหกนาที ไม่มีสิ่งใดเข้าถึงการผลิตได้จนกว่าจะผ่านการทดสอบสีเขียวทั้งหมด และรายงาน HTML จะถูกแนบไปกับการปรับใช้ทุกครั้งเพื่อเป็นหลักฐานการตรวจสอบ

ทีม SaaS ที่มี Public API ใช้เวอร์ชันที่กระชับกว่า: การควบคุมด้วย smoke test 12 สถานการณ์กับสภาพแวดล้อมสีเขียว จากนั้นทำการสลับ แล้วตามด้วย smoke test หลังการสลับกับ URL ที่ใช้งานจริง สิ่งที่พวกเขาให้ความสำคัญคือการตรวจจับการเปลี่ยนแปลงสคีมา เนื่องจาก third-party integrations จะทำงานผิดพลาดอย่างรุนแรงเมื่อโครงสร้างของฟิลด์เปลี่ยนไป การยืนยันสคีมาในการตอบกลับทุกครั้งคือหัวใจสำคัญของการควบคุมของพวกเขา

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

สรุป

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

องค์ประกอบต่างๆ:

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

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

ปุ่ม

คำถามที่พบบ่อย

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

ฉันจะทดสอบสภาพแวดล้อมสีเขียวก่อนสลับทราฟฟิกได้อย่างไร? กำหนดเป้าหมายชุดทดสอบ API ของคุณไปยัง URL พื้นฐานของสภาพแวดล้อมสีเขียวและรันมันในไปป์ไลน์ของคุณก่อนขั้นตอนการสลับใช้งาน ด้วย Apidog CLI ให้รันสถานการณ์ของคุณด้วย apidog run กับสภาพแวดล้อมสีเขียว หากมีการยืนยันใดๆ ล้มเหลว ให้ยกเลิกการปรับใช้ และสลับทราฟฟิกก็ต่อเมื่อชุดทดสอบผ่านเท่านั้น

ทำไมการตรวจสอบสถานะของโหลดบาลานเซอร์ถึงไม่เพียงพอสำหรับการปรับใช้แบบ blue-green? การตรวจสอบสถานะมักจะพิงไปยังเอนด์พอยต์หนึ่งและยืนยัน 200 ซึ่งพิสูจน์เพียงว่ากระบวนการทำงานอยู่ มันจะไม่สามารถตรวจจับฟิลด์ JSON ที่เปลี่ยนชื่อ, การย้ายข้อมูลที่ล้มเหลว, กระบวนการตรวจสอบสิทธิ์ที่เสีย, หรือการเปลี่ยนแปลงสคีมาได้ ชุดทดสอบ API จริงจะยืนยันเนื้อหาการตอบกลับ, สคีมา และกรณีข้อผิดพลาด ดังนั้นจึงสามารถตรวจจับความล้มเหลวที่การตรวจสอบสถานะมองข้ามไปได้

ฉันสามารถรันการทดสอบ API เดียวกันใน CI ที่ฉันสร้างในแอปเดสก์ท็อปได้หรือไม่? ได้ สถานการณ์ที่คุณสร้างด้วยภาพใน Apidog สามารถรันได้โดยไม่มีการเปลี่ยนแปลงจาก Apidog CLI คุณสร้างการกำหนดค่า CI สำหรับสถานการณ์ จากนั้นเรียกใช้ apidog run ด้วยการกำหนดค่านั้นใน GitHub Actions, GitLab CI, Jenkins หรือไปป์ไลน์ใดๆ CLI จะออกด้วยรหัสที่ไม่ใช่ศูนย์เมื่อเกิดความล้มเหลว ซึ่งช่วยให้คุณสามารถควบคุมการปรับใช้ได้

ความแตกต่างระหว่าง blue-green และ canary deployment ในการทดสอบคืออะไร? Blue-green สลับทราฟฟิกทั้งหมดในคราวเดียวหลังจากที่คุณทดสอบสภาพแวดล้อมสีเขียวที่ปรับใช้สมบูรณ์แล้ว ดังนั้นการควบคุมจะอยู่ก่อนการสลับ Canary จะค่อยๆ ย้ายทราฟฟิกไปยังส่วนเล็กๆ และอาศัยการตรวจสอบแบบสด (live monitoring) ของส่วนนั้น Blue-green ให้การควบคุมการทดสอบก่อนเผยแพร่ที่สะอาดกว่า; Canary ให้การเปิดเผยในโลกจริงแบบค่อยเป็นค่อยไป

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

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