วิธีตั้งค่าการทดสอบ API อัตโนมัติทุกคืนใน GitHub Actions, GitLab และ Jenkins

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

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

คู่มือนี้จะพาคุณสร้างระบบดังกล่าวตั้งแต่ต้นจนจบด้วย Apidog คุณจะได้ออกแบบชุดทดสอบรีเกรสชัน สร้างการรันด้วยคอมมานด์ไลน์ด้วย Apidog CLI เชื่อมต่อเข้ากับงาน CI ที่กำหนดเวลาไว้บน GitHub Actions, GitLab และ Jenkins และรับรายงานที่รอคุณอยู่ก่อนการประชุมสแตนด์อัพ หากคุณเคยแก้ไขข้อผิดพลาดที่ระบบรันตอนกลางคืนสามารถตรวจพบได้ล่วงหน้าหลายชั่วโมง นี่คือเวิร์กโฟลว์ที่จะช่วยให้คุณประหยัดเวลาเหล่านั้นได้

ทำไมการทดสอบแบบต่อคอมมิตถึงยังไม่พอ

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

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

• การพึ่งพาภายนอกมีการเปลี่ยนแปลง ผู้ให้บริการชำระเงินเปลี่ยนคีย์แซนด์บ็อกซ์ API สภาพอากาศเลิกใช้ฟิลด์บางอย่าง โค้ดของคุณยังคงเดิม แต่สัญญาเปลี่ยนไปโดยที่คุณไม่รู้ตัว
• ข้อมูลมีการเปลี่ยนแปลงโดยไม่มีการเปลี่ยนแปลงโค้ด งาน ETL ที่ทำงานข้ามคืน การย้ายข้อมูลตามกำหนดเวลา และการอัปเดตเนื้อหา สามารถทำให้ฐานข้อมูลของคุณอยู่ในสถานะที่การทดสอบแบบเร็วของคุณไม่เคยครอบคลุมถึง
• โทเค็นและใบรับรองหมดอายุ โทเค็น OAuth refresh, ใบรับรอง TLS และคีย์ API มีอายุการใช้งาน วันที่สิ่งใดสิ่งหนึ่งหมดอายุ การบิลด์สีเขียวของคุณก็คือการโกหก
• การถดถอยที่ช้าจะซ่อนอยู่ในการทดสอบแบบเร็ว การเรียกใช้คำสั่ง (query) ที่ใช้เวลาจาก 200 มิลลิวินาทีเป็น 1.2 วินาที จะไม่ทำให้การยืนยันการทำงานล้มเหลว แต่การรันตอนกลางคืนที่มีเกณฑ์เวลารอการตอบกลับจะตรวจพบได้
• ชุดทดสอบเต็มรูปแบบช้าเกินไปสำหรับการพุชทุกครั้ง การรันชุดทดสอบ 400 กรณีที่ครอบคลุมทุกปลายทาง ทุกกรณีขอบ และทุกสภาพแวดล้อมนั้นหนักเกินไปที่จะใช้เป็นเกณฑ์ในการอนุมัติ pull request การรันตอนกลางคืนคือที่ที่เหมาะสมสำหรับสิ่งเหล่านี้

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

อะไรบ้างที่ควรอยู่ในชุดทดสอบรีเกรสชัน API ตอนกลางคืน

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

ชุดทดสอบ API ตอนกลางคืนที่แข็งแกร่งจะครอบคลุมถึง:

• เส้นทางของผู้ใช้ที่สำคัญแบบ end-to-end ไม่ใช่แค่ปลายทางเดียวโดดๆ แต่เป็นห่วงโซ่การทำงานจริง เช่น ลงทะเบียน, เข้าสู่ระบบ, สร้างทรัพยากร, อ่านกลับ, อัปเดต, ลบ แต่ละขั้นตอนจะส่งโทเค็นและ ID ไปยังขั้นตอนถัดไป
• การยืนยันตัวตนและการอนุญาต การเข้าสู่ระบบที่ถูกต้อง การปฏิเสธโทเค็นที่หมดอายุ การเข้าถึงตามบทบาท การยืนยันตัวตนเป็นตัวร้ายที่ทำงานเงียบๆ ควรทดสอบทุกคืน
• การปฏิบัติตามสัญญา ทุกการตอบกลับจะถูกตรวจสอบกับ OpenAPI schema ของคุณ เพื่อให้แบ็กเอนด์ที่เงียบๆ ตัดฟิลด์ออกหรือเปลี่ยนประเภทจะถูกตรวจพบ หากเอกสารและการตอบกลับของคุณมักจะคลาดเคลื่อนจากกัน นี่คือการตรวจสอบที่จะจับมันได้ (ดู ทำไมเอกสาร Swagger และคอลเลกชันถึงคลาดเคลื่อนอยู่เสมอ สำหรับกลไก)
• กรณีขอบเขตและข้อผิดพลาด รหัส 400 สำหรับข้อมูลป้อนเข้าที่ไม่ถูกต้อง, 404 สำหรับทรัพยากรที่หายไป, 429 สำหรับการจำกัดอัตรา (rate limit), 401 สำหรับไม่มีข้อมูลรับรอง เส้นทางที่ไม่ปกติมักจะเสียบ่อยกว่าเส้นทางปกติ
• ความถูกต้องของข้อมูลในคำขอต่างๆ สร้างบางสิ่งขึ้นมา แล้วยืนยันว่าคำขอในภายหลังเห็นสิ่งนั้น ตรวจจับข้อผิดพลาดเรื่อง eventual consistency และแคช
• เกณฑ์ประสิทธิภาพ ยืนยันว่าปลายทางหลักตอบสนองภายใต้งบประมาณที่กำหนด เส้นแนวโน้มตอนกลางคืนจะแสดงการเปลี่ยนแปลงที่ค่อยๆ เกิดขึ้นก่อนที่จะกลายเป็นเหตุการณ์ที่รุนแรง

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

ขั้นตอนที่ 1: สร้างชุดทดสอบรีเกรสชันใน Apidog

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

นี่คือรูปแบบของสถานการณ์ทดสอบรีเกรสชันการชำระเงิน (checkout):

1. POST /auth/login: ส่งข้อมูลรับรอง, ยืนยัน 200, ดึง accessToken จากการตอบกลับไปเก็บในตัวแปร
2. POST /carts: สร้างตะกร้าสินค้าโดยใช้โทเค็น, ยืนยัน 201, ดึง cartId
3. POST /carts/{cartId}/items: เพิ่มสินค้า, ยืนยัน 200, ยืนยันว่า total ในเนื้อหาการตอบกลับเท่ากับราคาที่คาดไว้
4. POST /checkout: ส่งตะกร้าสินค้า, ยืนยัน 200, ยืนยันว่า order.status คือ "confirmed"
5. GET /orders/{orderId}: อ่านคำสั่งซื้อกลับมา, ยืนยันว่าคงอยู่พร้อมกับรายการสินค้าที่ถูกต้อง

ใน Apidog คุณสร้างสิ่งนี้ได้ด้วยภาพ แต่ละขั้นตอนมีการยืนยันโดยไม่ต้องเขียนโค้ดซ้ำซ้อน: การยืนยันด้วยภาพ เช่น “สถานะการตอบกลับคือ 200” หรือ “JSONPath $.order.status เท่ากับ confirmed” สำหรับการปฏิบัติตาม schema Apidog สามารถตรวจสอบการตอบกลับกับคำจำกัดความ OpenAPI ที่บันทึกไว้ของปลายทางได้โดยอัตโนมัติ ดังนั้นคุณไม่จำเป็นต้องเขียนการตรวจสอบด้วยมือสำหรับทุกฟิลด์

กฎการออกแบบบางอย่างช่วยให้ชุดทดสอบตอนกลางคืนสามารถดูแลรักษาได้:

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

หากคุณมาจากเครื่องมืออื่น สิ่งนี้จะเชื่อมโยงกับแนวคิดที่คุณรู้จักอย่างชัดเจน ภาพรวมที่กว้างขึ้นของการเรียงร้อยสถานการณ์เข้าด้วยกันอยู่ใน คู่มือการจัดการการทดสอบ API (API test orchestration guide) และหากคุณไม่เคยรันการทดสอบที่มีโครงสร้างใน Apidog มาก่อน วิธีการทดสอบ API ด้วย Apidog คือจุดเริ่มต้นแบบทีละขั้นตอน ดาวน์โหลด Apidog และสร้างสถานการณ์หนึ่งขึ้นมาก่อนที่คุณจะอ่านต่อ ส่วนที่เหลือของคู่มือนี้จะถือว่าคุณมีชุดทดสอบพร้อมที่จะรันแล้ว

ขั้นตอนที่ 2: รันชุดทดสอบจากคอมมานด์ไลน์

การบิลด์ตอนกลางคืนจะทำงานโดยไม่ต้องมีคนดูแล ดังนั้นจึงต้องใช้ headless runner นั่นคือ Apidog CLI ซึ่งเป็นแพ็กเกจ npm ที่รันสถานการณ์ทดสอบที่คุณบันทึกไว้จากเทอร์มินัลใดก็ได้ โดยไม่จำเป็นต้องใช้ GUI มันถูกสร้างมาเพื่อสิ่งนี้โดยเฉพาะ: การรันอัตโนมัติภายในไปป์ไลน์ CI/CD

ติดตั้งแบบ global CLI ต้องใช้ Node.js v16 หรือใหม่กว่า

npm install -g apidog-cli

ในการรันสถานการณ์ออนไลน์ (สถานการณ์ที่อยู่ในโปรเจกต์ Apidog ของคุณ) คุณต้องมีสองสิ่ง: access token และ ID ของสถานการณ์หรือชุดทดสอบ สร้างโทเค็นใน Apidog ใต้การตั้งค่า CI/CD ซึ่งมีปุ่ม “Add access token” ปฏิบัติต่อโทเค็นนั้นเหมือนรหัสผ่าน; มันควรอยู่ในความลับ ไม่ควรอยู่ใน repository ของคุณเด็ดขาด

คำสั่งในการรันสถานการณ์ทดสอบเดียวมีลักษณะดังนี้:

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t 123456 \
  -e 789 \
  -r cli,html \
  --out-dir ./apidog-reports

อธิบายทีละแฟล็ก โดยใช้ตัวเลือก Apidog CLI จริง:

• --access-token <token> ใช้สำหรับการยืนยันตัวตนในการรัน ส่งค่าจากตัวแปรสภาพแวดล้อม
• -t, --test-scenario <id> เลือกสถานการณ์ที่จะรัน หากต้องการรันทั้งชุดทดสอบ ให้ใช้ --test-suite <id>; หากต้องการรันโฟลเดอร์ของสถานการณ์ ให้ใช้ -f, --test-scenario-folder <id>
• -e, --environment <id> เลือกสภาพแวดล้อม (staging, production-readonly, ฯลฯ)
• -r, --reporters [reporters] กำหนดรูปแบบเอาต์พุต cli จะพิมพ์ผลลัพธ์ออกไปยังคอนโซลสำหรับบันทึก CI ของคุณ; html จะสร้างไฟล์รายงานที่สามารถแชร์ได้
• --out-dir <dir> คือที่ที่รายงาน HTML จะถูกบันทึก เพื่อให้ CI สามารถเก็บถาวรเป็น artifact ได้

แฟล็กอื่นๆ ก็มีประโยชน์ในการรันตอนกลางคืน -n, --iteration-count <n> ทำซ้ำการรันเพื่อเผยให้เห็นความไม่เสถียร -d, --iteration-data <path> ป้อนไฟล์ CSV หรือ JSON เพื่อให้สถานการณ์เดียวทำงานกับข้อมูลหลายแถว เหมาะสำหรับการทดสอบขอบเขต --env-var "key=value" และ --global-var "key=value" ฉีดค่าในขณะรัน ซึ่งเป็นวิธีที่คุณเก็บข้อมูลรับรองออกจากสถานการณ์ที่บันทึกไว้

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

ขั้นตอนที่ 3: กำหนดเวลาให้เป็น nightly build

การบิลด์ตอนกลางคืนคือการใช้คำสั่งนี้ตามเวลาที่กำหนด ทุกแพลตฟอร์ม CI รองรับงานที่กำหนดเวลาไว้ผ่านไวยากรณ์ cron รูปแบบจะเหมือนกันทั้งหมด: ตัวกระตุ้นรายวัน, access token จากความลับ, การรัน CLI, และรายงานที่เก็บถาวรเป็น artifact

GitHub Actions

GitHub Actions รองรับทริกเกอร์ schedule ด้วย cron มาตรฐาน เวิร์กโฟลว์นี้จะทำงานเวลา 02:00 UTC ทุกวัน และยังเปิดใช้งานปุ่มสั่งงานด้วยตนเองผ่าน workflow_dispatch

name: Nightly API Regression

on:
  schedule:
    - cron: '0 2 * * *'   # 02:00 UTC daily
  workflow_dispatch:        # allow manual runs

jobs:
  regression:
    runs-on: ubuntu-latest
    steps:
      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run nightly regression suite
        run: |
          apidog run \
            --access-token $APIDOG_ACCESS_TOKEN \
            --test-suite ${{ vars.APIDOG_SUITE_ID }} \
            -e ${{ vars.APIDOG_ENV_ID }} \
            -r cli,html \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

      - name: Upload HTML report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-nightly-report
          path: ./apidog-reports

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

GitLab CI/CD

GitLab กำหนดเวลาไปป์ไลน์ผ่าน UI (CI/CD > Schedules) แทนที่จะอยู่ใน YAML จากนั้นงานของคุณจะอิงตามเงื่อนไขกฎ (rules condition) เพื่อให้ทำงานเฉพาะตามกำหนดเวลาเท่านั้น ไม่ใช่ทุกครั้งที่มีการพุช

nightly-regression:
  image: node:20
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  before_script:
    - npm install -g apidog-cli
  script:
    - apidog run
        --access-token "$APIDOG_ACCESS_TOKEN"
        --test-suite "$APIDOG_SUITE_ID"
        -e "$APIDOG_ENV_ID"
        -r cli,html
        --out-dir ./apidog-reports
  artifacts:
    when: always
    paths:
      - apidog-reports/
    expire_in: 30 days

ตั้งค่า APIDOG_ACCESS_TOKEN เป็นตัวแปร CI/CD แบบที่ถูกซ่อนและป้องกันไว้ จากนั้นสร้างกำหนดเวลาไปป์ไลน์ด้วยนิพจน์ cron เช่น 0 2 * * * บล็อก rules จะป้องกันไม่ให้งานนี้ทำงานในการคอมมิตปกติ

Jenkins

ใน Jenkins, pipeline ที่มีทริกเกอร์ cron จะทำงานเดียวกัน จัดเก็บโทเค็นเป็นข้อมูลรับรอง (credential) และดึงมาใช้งานด้วย withCredentials

pipeline {
    agent any
    triggers {
        cron('H 2 * * *')   // around 02:00, H spreads load
    }
    stages {
        stage('Install CLI') {
            steps { sh 'npm install -g apidog-cli' }
        }
        stage('Nightly regression') {
            steps {
                withCredentials([string(credentialsId: 'apidog-token',
                                        variable: 'APIDOG_ACCESS_TOKEN')]) {
                    sh '''
                        apidog run \
                          --access-token $APIDOG_ACCESS_TOKEN \
                          --test-suite $APIDOG_SUITE_ID \
                          -e $APIDOG_ENV_ID \
                          -r cli,html \
                          --out-dir ./apidog-reports
                    '''
                }
            }
        }
    }
    post {
        always {
            archiveArtifacts artifacts: 'apidog-reports/**', allowEmptyArchive: true
        }
    }
}

ตัวอักษร H ใน H 2 * * * เป็นคุณสมบัติที่ดีของ Jenkins: มันจะเลือกนาทีที่คงที่ภายในชั่วโมง เพื่อไม่ให้งานตอนกลางคืนทั้งหมดของคุณทำงานพร้อมกันที่เวลา 02:00 น. เป๊ะๆ

ฟิลด์ cron นั้นเหมือนกันในทั้งสามแพลตฟอร์ม 0 2 * * * หมายถึงนาทีที่ 0, ชั่วโมงที่ 2, ทุกวัน ต้องการให้รันสองครั้งต่อคืนเพื่อตรวจจับปัญหาเร็วขึ้นหรือไม่? ใช้ 0 2,14 * * * ต้องการเฉพาะวันธรรมดา? ใช้ 0 2 * * 1-5 เลือกเวลาที่สภาพแวดล้อม staging ของคุณเงียบสงบและแซนด์บ็อกซ์ภายนอกกำลังทำงาน

ขั้นตอนที่ 4: ทำให้ความล้มเหลวเป็นสิ่งที่ละเลยไม่ได้

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

รหัสออก (exit code) ของ CLI คือตัวเชื่อมโยงของคุณ apidog run จะออกจากระบบด้วยรหัสที่ไม่ใช่ศูนย์เมื่อสถานการณ์ล้มเหลว ดังนั้น CI จะเปลี่ยนสถานะงานเป็นสีแดงโดยอัตโนมัติ จากจุดนั้น:

• ให้ CI แจ้งเตือนด้วยตัวเอง GitHub Actions, GitLab และ Jenkins ล้วนส่งอีเมลหรือข้อความแจ้งทีมที่รับผิดชอบเมื่อการรันตามกำหนดเวลาล้มเหลว เปิดใช้งานซะ
• โพสต์ไปยังแชท เพิ่มขั้นตอนที่จะส่งข้อความ Slack หรือ webhook เมื่อเกิดความล้มเหลว พร้อมลิงก์ไปยังการรันและรายงาน HTML ที่เก็บถาวร รายงานจะแสดงให้เห็นว่าสถานการณ์ใด ขั้นตอนใด และการยืนยันใดที่ล้มเหลว ทำให้นักพัฒนาที่เข้าเวรสามารถเริ่มแก้ไขข้อบกพร่องได้ทันที แทนที่จะต้องพยายามทำซ้ำปัญหา
• ติดตามแนวโน้ม ไม่ใช่แค่การผ่าน/ไม่ผ่าน Apidog สามารถอัปโหลดรายงานเพื่อให้คุณเก็บประวัติได้ การเห็นสีแดงเพียงคืนเดียวคือสัญญาณรบกวน; แต่สามคืนติดต่อกันบนปลายทางเดียวกันคือสัญญาณที่แท้จริง

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

ทำไม Apidog จึงเหมาะกับรูปแบบ nightly

คุณสามารถประกอบไปป์ไลน์ API แบบ nightly จากส่วนต่างๆ ได้: เครื่องมือหนึ่งสำหรับการออกแบบ, อีกเครื่องมือหนึ่งสำหรับการเขียนการทดสอบ, เครื่องมือที่สามสำหรับการรันแบบ headless และตัวตรวจสอบ schema ที่ต่อเพิ่มเข้าไป หลายทีมทำงานในลักษณะนั้น และมันก็ใช้ได้ผลจนกว่าส่วนต่างๆ จะเริ่มคลาดเคลื่อนจากกัน ความยุ่งยากจะเกิดขึ้นตอนตี 2 เมื่อการทดสอบที่รันไม่ตรงกับ API ที่คุณปล่อยออกไปใช้งานจริงแล้ว

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

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

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

Nightly build กับ Continuous integration แตกต่างกันอย่างไร?

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

Nightly build ควรทำงานเมื่อไหร่?

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

ฉันสามารถรัน nightly suite กับ production ได้หรือไม่?

รันการตรวจสอบแบบอ่านอย่างเดียว (read-only checks) กับ production ได้อย่างปลอดภัย สำหรับสิ่งที่เขียนข้อมูล ให้ชี้ nightly suite ไปยังสภาพแวดล้อม staging หรือ pre-production ที่มีข้อมูลจริงโดยเฉพาะ หรือใช้ idempotent operations และขั้นตอนการล้างข้อมูล รูปแบบทั่วไปคือการรันรีเกรสชันแบบอ่าน-เขียนเต็มรูปแบบกับ staging ควบคู่ไปกับการรัน smoke test แบบอ่านอย่างเดียวขนาดเล็กกับ production เพื่อยืนยันว่าระบบจริงสามารถเข้าถึงได้และตอบสนองอย่างถูกต้อง

สิ่งนี้แตกต่างจากการมอนิเตอร์อย่างไร?

การมอนิเตอร์สถานะการทำงาน (uptime monitoring) จะตอบคำถามว่า “API ทำงานอยู่หรือไม่?” ชุดทดสอบรีเกรสชันตอนกลางคืนจะตอบคำถามว่า “API ทำงานถูกต้องหรือไม่?” การมอนิเตอร์จะส่ง ping ไปยังปลายทางและตรวจสอบว่าได้รหัส 200 การรันรีเกรสชันจะทดสอบเวิร์กโฟลว์เต็มรูปแบบ ตรวจสอบเนื้อหาการตอบกลับกับ schema ของคุณ ตรวจสอบขอบเขตการยืนยันตัวตน และยืนยันกฎทางธุรกิจ ทั้งสองอย่างนี้เป็นส่วนเสริมกัน; การมอนิเตอร์เป็นการทำงานต่อเนื่องและตื้นเขิน ส่วนการทดสอบตอนกลางคืนเป็นการทำงานตามช่วงเวลาและลึกซึ้ง

ฉันจำเป็นต้องเขียนโค้ดเพื่อกำหนดเวลาการทดสอบ API หรือไม่?

ไม่จำเป็น คุณสร้างสถานการณ์ด้วยภาพใน Apidog โดยไม่ต้องเขียนสคริปต์ จากนั้นคัดลอกคำสั่ง apidog run ที่สร้างขึ้นจากแผง CI/CD "โค้ด" เดียวที่คุณต้องมีคือไม่กี่บรรทัดใน YAML หรือไฟล์คอนฟิกไปป์ไลน์ที่บอกแพลตฟอร์ม CI ของคุณว่าเมื่อไหร่ควรรัน ซึ่งก็คือเทมเพลตด้านบน หากคุณต้องการดูว่า command-line runners เปรียบเทียบกันอย่างไรโดยทั่วไป Postman CLI เทียบกับ Newman และ การรันคอลเลกชันใน CI โดยไม่มี Newman ครอบคลุมทางเลือกอื่นๆ

ตั้งค่า nightly run ครั้งแรกของคุณ

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

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