كيفية إعداد اختبارات API آلية يومية في GitHub Actions و GitLab و Jenkins

تجاوزت اختبارات واجهة برمجة التطبيقات (API) الخاصة بك كل طلب سحب. البناء أخضر. تقوم بالنشر. ثم في الساعة 9 صباحًا، يبلغ شخص ما في منطقة زمنية أخرى أن عملية الدفع تُرجع خطأ 500، ولم يقم أحد بتغيير رمز الدفع. ما تغير هو بيئة اختبار دفع تابعة لجهة خارجية، أو ترحيل قاعدة بيانات تم تشغيله خلال الليل، أو رمز انتهت صلاحيته بصمت. لم تكتشف اختباراتك لكل التزام هذا أبدًا لأنه لم يتحرك شيء في مستودعك.

هذه هي الفجوة التي يسدها البناء الليلي. البناء الليلي هو تشغيل اختبار كامل ومجدول يتم إطلاقه مرة واحدة يوميًا، عادة في الساعات الأولى من الصباح، مقابل خدماتك وبيئاتك الحقيقية بدلاً من الاقتصار على تغييرات التعليمات البرمجية. إنه يكشف عن الإخفاقات التي تحدث بين الالتزامات: انحراف البيانات، والتكاملات المتقلبة، وبيانات الاعتماد منتهية الصلاحية، والتسريبات البطيئة في الأداء، وخرق العقود التي أدخلتها خدمات لا تتحكم فيها. بالنسبة لواجهات برمجة التطبيقات على وجه التحديد، فإن تشغيل الانحدار الليلي هو أرخص نظام إنذار مبكر يمكنك إعداده.

يرشدك هذا الدليل خلال بناء هذا النظام من البداية إلى النهاية باستخدام Apidog. ستقوم بتصميم مجموعة انحدار، وتوليد تشغيل من سطر الأوامر باستخدام Apidog CLI، وربطها بوظيفة CI مجدولة على GitHub Actions وGitLab وJenkins، وستحصل على تقرير في انتظارك قبل اجتماع الصباح. إذا سبق لك تصحيح خطأ انقطاع كان من الممكن أن يكشف عنه تشغيل ليلي قبل ساعات، فإن سير العمل هذا هو الذي يعيد لك تلك الساعات.

زر التحميل

لماذا لا تكفي الاختبارات لكل التزام

لقد دربتنا التكامل المستمر على الاختبار عند كل عملية دفع. هذا جيد، ويجب أن تستمر في القيام بذلك. لكن الاختبارات لكل التزام تجيب على سؤال ضيق: "هل أدى هذا التغيير إلى تعطيل شيء ما؟" إنها تعمل بسرعة، وتعمل بشكل متكرر، ونطاقها محدد لإبقاء المطورين غير محجوبين. هذا النطاق هو بالضبط السبب في أنها تفوت فئة كاملة من المشاكل.

يجيب البناء الليلي على سؤال أوسع: "هل لا يزال النظام سليمًا الآن، بغض النظر عما إذا كان أي شخص قد لمسه؟" يهم هذا الاختلاف لأن بيئة الإنتاج تحتوي على أجزاء متحركة لا تراها التزاماتك أبدًا.

**انحراف التبعيات الخارجية.** يغير مزود خدمة الدفع مفتاح بيئة الاختبار. تقوم واجهة برمجة تطبيقات الطقس بإهمال حقل. رمزك مطابق، لكن العقد تغير من تحتك.
**تغير البيانات بدون رمز.** يمكن لوظائف ETL الليلية، والترحيلات المجدولة، وتحديثات المحتوى أن تضع قاعدة بياناتك في حالة لا تختبرها اختباراتك السريعة أبدًا.
**انتهاء صلاحية الرموز والشهادات.** رموز تحديث OAuth، وشهادات TLS، ومفاتيح API لها عمر افتراضي. في اليوم الذي تنتهي فيه صلاحية إحداها، يكون بناءك الأخضر كذبة.
**تختبئ الانحدارات البطيئة في المجموعات السريعة.** استعلام يتسلل من 200 مللي ثانية إلى 1.2 ثانية لن يفشل تأكيدًا وظيفيًا، لكن تشغيلًا ليليًا بحد استجابة زمني سيفعل ذلك.
**المجموعات الكاملة بطيئة جدًا لكل عملية دفع.** التشغيل الشامل الذي يتضمن 400 حالة ويضرب كل نقطة نهاية، وكل حالة حافة، وكل بيئة، ثقيل جدًا ليكون بوابة لطلب السحب. الليلي هو مكانه الصحيح.

لذلك النمط ذو مستويين، وليس خيارًا بين هذا وذاك. تحمي اختبارات الدخان السريعة كل التزام. بينما تعمل مجموعة انحدار أعمق وفق جدول زمني. الطبقة الليلية هي المكان الذي تضع فيه كل ما هو بطيء جدًا، أو واسع جدًا، أو يعتمد كثيرًا على العالم الحقيقي ليكون جزءًا من الحلقة الداخلية.

ماذا يتضمن جناح انحدار واجهة برمجة التطبيقات الليلي؟

قبل أن تجدول أي شيء، قرر ما الذي يختبره التشغيل الليلي بالفعل. مجموعة الاختبار الليلية أوسع من اختبارات الدخان التي تعمل عند الالتزام وأكثر شمولاً من فحص صحة سريع. اهدف إلى تغطية قد تحرجك إذا تعطلت بصمت.

تغطي مجموعة واجهة برمجة التطبيقات الليلية القوية ما يلي:

**رحلات المستخدم الحرجة، من البداية إلى النهاية.** ليست نقاط نهاية منفردة بمعزل عن غيرها؛ بل السلاسل الحقيقية. التسجيل، تسجيل الدخول، إنشاء مورد، قراءته مرة أخرى، تحديثه، حذفه. كل خطوة تمرر الرموز والمعرفات إلى التالية.
**المصادقة والتفويض.** تسجيل دخول صالح، رفض الرمز منتهي الصلاحية، الوصول القائم على الأدوار. المصادقة هي القاتل الصامت؛ اختبرها كل ليلة.
**التوافق مع العقد.** يتم التحقق من صحة كل استجابة مقابل مخطط OpenAPI الخاص بك حتى يتم اكتشاف الواجهة الخلفية التي تسقط حقلًا بهدوء أو تغير نوعًا. إذا كانت وثائقك واستجاباتك تميل إلى الانحراف، فهذا هو الفحص الذي يكتشفه. (راجع لماذا تنحرف وثائق ومجموعات Swagger باستمرار للآليات.)
**حالات الحدود والأخطاء.** 400s على إدخال خاطئ، 404s على الموارد المفقودة، 429s تحت حدود المعدل، 401s بدون بيانات اعتماد. المسارات غير السعيدة تتعطل في كثير من الأحيان أكثر من المسارات السعيدة.
**سلامة البيانات عبر الطلبات.** أنشئ شيئًا ما، ثم تأكد من أن طلبًا لاحقًا يراه. اكتشف أخطاء الاتساق النهائي والتخزين المؤقت.
**عتبات الأداء.** تأكد من أن نقاط النهاية الرئيسية تستجيب ضمن ميزانية محددة. يظهر خط الاتجاه الليلي الزحف قبل أن يصبح حادثًا.

إذا لم يسبق لك كتابة حالات منظمة مثل هذه، فإن قالب ومثال حالة اختبار واجهة برمجة التطبيقات هو نقطة بداية جيدة، وتأكيدات واجهة برمجة التطبيقات تغطي كيفية التحقق من صحة نص الاستجابة، والحالة، والرؤوس، والتوقيت بدقة.

الخطوة 1: بناء مجموعة الانحدار في Apidog

يعامل Apidog الاختبار كجزء أساسي من دورة حياة واجهة برمجة التطبيقات، وليس إضافة ملحقة. تقوم بتصميم نقاط النهاية، ثم تربطها في سيناريوهات اختبار تحاكي سير العمل الحقيقي. السيناريو هو قائمة مرتبة من الخطوات حيث كل خطوة هي طلب واجهة برمجة تطبيقات مع تأكيدات، وحيث تتدفق البيانات من خطوة إلى أخرى.

إليك شكل سيناريو انحدار عملية الدفع:

**POST /auth/login**: إرسال بيانات الاعتماد، التأكد من 200، استخراج `accessToken` من الاستجابة إلى متغير.
**POST /carts**: إنشاء سلة باستخدام الرمز، التأكد من 201، استخراج `cartId`.
**POST /carts/{cartId}/items**: إضافة منتج، التأكد من 200، التأكد من أن `total` في نص الاستجابة يساوي السعر المتوقع.
**POST /checkout**: إرسال السلة، التأكد من 200، التأكد من أن `order.status` هو "confirmed".
**GET /orders/{orderId}**: قراءة الطلب مرة أخرى، التأكد من أنه تم حفظه بعناصر الخط الصحيحة.

في Apidog، تقوم ببناء هذا بصريًا. تحصل كل خطوة على تأكيدات دون كتابة رمز متكرر: تأكيد بصري مثل "حالة الاستجابة هي 200" أو "JSONPath $.order.status يساوي confirmed". للتوافق مع المخطط، يمكن لـ Apidog التحقق من صحة الاستجابة مقابل تعريف OpenAPI المحفوظ لنقطة النهاية تلقائيًا، لذلك لا تحتاج إلى كتابة فحص يدوي لكل حقل.

قواعد تصميم قليلة تحافظ على قابلية صيانة مجموعة الاختبار الليلية:

**استخدم البيئات، وليس عناوين URL المكتوبة يدويًا.** حدد بيئة `staging` مع عنوان URL الأساسي الخاص بها، وبيانات الاعتماد، والمتغيرات. يتم تشغيل نفس السيناريو مقابل بيئة staging الليلة ومقابل مرشح إصدار الأسبوع المقبل عن طريق تبديل علامة واحدة.
**الاستخدام البارامتري مع المتغيرات.** اسحب اسم المستخدم للاختبار، وعنوان URL الأساسي، وأي معرفات من متغيرات البيئة بحيث لا يعيش أي شيء سري أو خاص بالبيئة في السيناريو نفسه.
**تجميع السيناريوهات في مجموعة اختبار.** تجمع مجموعة الاختبار العديد من السيناريوهات بحيث يقوم أمر واحد بتشغيلها جميعًا. هذه هي الوحدة التي ستقوم بجدولتها.

إذا كنت قادمًا من أداة أخرى، فإن هذا يتوافق بشكل واضح مع المفاهيم التي تعرفها. الصورة الأوسع لربط السيناريوهات معًا موجودة في دليل تنسيق اختبار واجهة برمجة التطبيقات، وإذا لم يسبق لك تشغيل اختبار منظم في Apidog من قبل، فإن كيفية اختبار واجهة برمجة التطبيقات باستخدام Apidog هي نقطة البداية خطوة بخطوة. قم بتنزيل Apidog وقم ببناء سيناريو واحد قبل المتابعة في القراءة؛ يفترض بقية هذا الدليل أن لديك مجموعة جاهزة للتشغيل.

الخطوة 2: تشغيل المجموعة من سطر الأوامر

يتم تشغيل البناء الليلي بدون إشراف، لذلك فهو يحتاج إلى مُشغّل بدون واجهة رسومية. هذا هو Apidog CLI، حزمة npm تقوم بتشغيل سيناريوهات الاختبار المحفوظة لديك من أي طرفية، بدون الحاجة إلى واجهة رسومية. لقد تم بناؤه لهذا الغرض تحديدًا: التشغيل التلقائي داخل مسار CI/CD.

npm install -g apidog-cli

لتشغيل سيناريو عبر الإنترنت (واحد موجود في مشروع Apidog الخاص بك)، تحتاج إلى شيئين: رمز وصول ومعرف السيناريو أو المجموعة. أنشئ الرمز المميز في Apidog ضمن إعدادات CI/CD، حيث يوجد زر "إضافة رمز وصول". تعامل مع هذا الرمز ككلمة مرور؛ يجب أن يوضع في سر، وليس في مستودعك أبدًا.

الأمر لتشغيل سيناريو اختبار واحد يبدو كالتالي:

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

خيارًا بخيار، باستخدام خيارات Apidog CLI الحقيقية:

`--access-token` يصادق على التشغيل. قم بتمريره من متغير بيئة.
`-t, --test-scenario` يختار السيناريو المراد تشغيله. لتشغيل مجموعة كاملة بدلاً من ذلك، استخدم `--test-suite`؛ لتشغيل مجلد من السيناريوهات، استخدم `-f, --test-scenario-folder`.
`-e, --environment` يختار البيئة (staging، production-readonly، إلخ).
`-r, --reporters [reporters]` يحدد تنسيق الإخراج. `cli` يطبع النتائج إلى وحدة التحكم لسجلات CI الخاصة بك؛ `html` ينتج ملف تقرير قابل للمشاركة.
`--out-dir` هو المكان الذي يهبط فيه تقرير HTML حتى تتمكن CI من أرشفته كأثر.

خيارات أخرى تستحق مكانها في التشغيل الليلي. `-n, --iteration-count` يكرر التشغيل للكشف عن التقلبات. `-d, --iteration-data` يغذي ملف CSV أو JSON بحيث يتم تشغيل سيناريو واحد عبر العديد من صفوف البيانات؛ مثالي لاختبار الحدود. `--env-var "key=value"` و`--global-var "key=value"` يحقنان القيم في وقت التشغيل، وهي الطريقة التي تحافظ بها على بيانات الاعتماد خارج السيناريو المحفوظ.

ليس عليك حفظ هذا. يقوم Apidog بتوليد الأمر الدقيق لك: افتح لوحة CI/CD في العميل، اختر السيناريو أو المجموعة الخاصة بك، وانسخ سطر apidog run الجاهز مباشرة إلى تهيئة مسارك. قم بتشغيله مرة واحدة محليًا أولاً للتأكد من أنه أخضر قبل جدولته.

الخطوة 3: جدولة تشغيله كبناء ليلي

البناء الليلي هو هذا الأمر على مؤقت. تدعم جميع منصات CI الوظائف المجدولة من خلال صيغة cron. النمط متطابق عبر جميعها: مشغل يومي، ورمز الوصول من سر، وتشغيل CLI، والتقرير المؤرشف كأثر.

إجراءات GitHub (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 مسارات الأنابيب عبر واجهة المستخدم (CI/CD > Schedules) بدلاً من YAML، ثم تعتمد وظيفتك على شرط القواعد بحيث لا يتم تشغيلها إلا وفقًا للجدول الزمني، وليس عند كل عملية دفع.

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` بنفس المهمة. قم بتخزين الرمز كبيانات اعتماد واسحبه باستخدام `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: اجعل الإخفاقات من المستحيل تجاهلها

التشغيل الليلي الذي يفشل في سجل لا يقرأه أحد أسوأ من عدم وجود تشغيل ليلي على الإطلاق؛ فهو يبني ثقة زائفة. الهدف كله هو التنبيه. اربط النتيجة بالمكان الذي ينظر إليه فريقك بالفعل.

رمز الخروج الخاص بـ CLI هو نقطة الربط الخاصة بك. يخرج `apidog run` بقيمة غير صفرية عندما يفشل السيناريو، لذا تقوم CI بتحويل المهمة إلى اللون الأحمر تلقائيًا. ومن هناك:

**دع CI يقوم بالإشعار بنفسه.** تقوم GitHub Actions وGitLab وJenkins جميعها بإرسال بريد إلكتروني أو رسالة إلى الفريق المسؤول عند فشل تشغيل مجدول. قم بتشغيل هذه الميزة.
**النشر إلى الدردشة.** أضف خطوة ترسل رسالة Slack أو webhook عند الفشل مع رابط للتشغيل وتقرير HTML المؤرشف. يوضح التقرير السيناريو الذي فشل، والخطوة التي فشلت، والتأكيد الذي تعطل، بحيث يبدأ المهندس المناوب في تصحيح الأخطاء بدلاً من إعادة إنتاجها.
**تتبع الاتجاه، وليس فقط النجاح/الفشل.** يمكن لـ Apidog تحميل التقرير بحيث تحتفظ بسجل. ليلة حمراء واحدة هي مجرد ضوضاء؛ ثلاث ليال حمراء متتالية على نفس نقطة النهاية هي إشارة.

يُبقي انضباط واحد البنى الليلية جديرة بالثقة: عامل الفشل كخطأ حقيقي حتى يثبت العكس. أسرع طريقة لقتل مجموعة ليلية هي السماح للاختبارات المتقلبة بتدريب الجميع على تجاهل اللون الأحمر. إذا فشل سيناريو بشكل متقطع، قم بإصلاح الاختبار أو البيئة؛ لا تتجاهله. التشغيل باستخدام -n لتكرار السيناريو، أو تثبيت البيانات التي يعتمد عليها السيناريو الخاص بك، يكشف عادةً عن المشكلة الحقيقية.

لماذا يتوافق Apidog مع نمط البناء الليلي

يمكنك تجميع مسار عمل واجهة برمجة تطبيقات ليلي من أجزاء منفصلة: أداة واحدة للتصميم، وأخرى لكتابة الاختبارات، وثالثة لتشغيلها بدون واجهة رسومية، ومدقق مخطط مدمج. العديد من الفرق تعمل بهذه الطريقة، وتنجح حتى تتشتت الأجزاء وتخرج عن التزامن. يظهر الاحتكاك في الساعة 2 صباحًا عندما لم يعد الاختبار الذي يقوم المشغل بتنفيذه يتطابق مع واجهة برمجة التطبيقات التي قمت بنشرها فعليًا.

يجمع Apidog كل ذلك في سير عمل واحد. نقطة النهاية التي تصممها، السيناريو الذي تختبره، المخطط الذي تتحقق منه، والأمر الذي تجدوله، كلها تشير إلى نفس مصدر الحقيقة. عندما تغير نقطة نهاية، يتحرك السيناريو وفحص المخطط معها. لا توجد خطوة تصدير، لا توجد مجموعة تصبح قديمة بصمت، لا توجد نسخة ثانية من العقد للحفاظ على التزامن. إذا شعرت بألم مجموعات Postman التي ليست مصدرًا حقيقيًا للحقيقة، فإن هذا التصميم أحادي المصدر هو الفارق.

CLI هو نفس المحرك مثل واجهة المستخدم الرسومية (GUI)، لذا فإن السيناريو الذي تقوم بتصحيحه بصريًا على مكتبك يعمل بشكل متطابق في CI في الساعة 2 صباحًا. يمكنك بناء وإصلاح الاختبارات برؤية كاملة، ثم تشغيلها بدون واجهة رسومية بأمر واحد. هذا التماثل هو ما يجعل البناء الليلي شيئًا تثق به بدلاً من شيء تقوم برعايته.

الأسئلة الشائعة

ما الفرق بين البناء الليلي والتكامل المستمر؟

يقوم التكامل المستمر بتشغيل الاختبارات على كل تغيير في الكود لالتقاط الانحدارات في الالتزامات الجديدة. بينما يعمل البناء الليلي بجدول زمني ثابت، عادةً خلال الليل، بغض النظر عما إذا كان هناك أي تغيير. تلتقط CI ما يفسده فريقك؛ بينما يلتقط التشغيل الليلي ما يفسده العالم الخارجي: الرموز المميزة منتهية الصلاحية، والتبعيات المنحرفة، وتغييرات البيانات، والتدهور البطيء في الأداء. تعمل مسارات العمل الناضجة على تشغيل كلاهما. تحمي اختبارات الدخان السريعة كل التزام، بينما يتم تشغيل مجموعة انحدار أوسع ليلاً.

متى يجب أن يتم تشغيل البناء الليلي؟

اختر وقتًا تكون فيه بيئة الاختبار الخاصة بك خاملة ويمكن الوصول إلى الخدمات الخارجية التي تعتمد عليها. بالنسبة للعديد من الفرق، يكون هذا من الساعة 1 صباحًا إلى 4 صباحًا بالتوقيت المحلي. إذا كانت واجهات برمجة التطبيقات الخاصة بك تستدعي بيئات اختبار تابعة لجهات خارجية، فتأكد من أنها نشطة في تلك الساعة؛ فبعض المزودين يقومون بتحديد السرعة أو الإيقاف المؤقت خلال الليل. تجنب الجدولة بالضبط على رأس الساعة في CI المشتركة، حيث يتم تشغيل آلاف الوظائف في وقت واحد؛ فالتأخير بضع دقائق (أو استخدام صيغة `H` في Jenkins) يوزع الحمل.

هل يمكنني تشغيل مجموعة اختبار ليلية ضد بيئة الإنتاج؟

قم بتشغيل فحوصات للقراءة فقط ضد بيئة الإنتاج بأمان. بالنسبة لأي شيء يكتب بيانات، وجه المجموعة الليلية نحو بيئة staging أو ما قبل الإنتاج مخصصة تحتوي على بيانات واقعية، أو استخدم عمليات متطابقة خطية وخطوة تنظيف. النمط الشائع هو تشغيل انحدار كامل للقراءة والكتابة ضد بيئة staging بالإضافة إلى تشغيل دخان صغير للقراءة فقط ضد بيئة الإنتاج للتأكد من أن النظام المباشر يمكن الوصول إليه ويستجيب بشكل صحيح.

كيف يختلف هذا عن المراقبة؟

تجيب مراقبة وقت التشغيل على السؤال "هل واجهة برمجة التطبيقات تعمل؟" بينما تجيب مجموعة الانحدار الليلية على السؤال "هل واجهة برمجة التطبيقات صحيحة؟" تقوم المراقبة بإرسال طلب إلى نقطة نهاية وتتحقق من رمز 200. يقوم تشغيل الانحدار بتنفيذ سير عمل كامل، ويتحقق من صحة نصوص الاستجابة مقابل مخططك، ويفحص حدود المصادقة، ويؤكد قواعد العمل. إنهما متكاملان؛ فالمراقبة مستمرة وسطحية، بينما الاختبار الليلي دوري وعميق.

هل أحتاج إلى كتابة كود لجدولة اختبارات واجهة برمجة التطبيقات؟

لا. يمكنك بناء السيناريوهات بصريًا في Apidog بدون أي برمجة نصية، ثم نسخ الأمر apidog run الذي تم إنشاؤه من لوحة CI/CD. "الرمز" الوحيد هو بضعة أسطر من YAML أو تهيئة مسار العمل التي تخبر منصة CI الخاصة بك متى يتم التشغيل، وتلك هي القوالب المذكورة أعلاه. إذا كنت تفضل رؤية كيفية مقارنة مشغلات سطر الأوامر بشكل عام، فإن Postman CLI مقابل Newman وتشغيل المجموعات في CI بدون Newman تغطي البدائل.

إعداد أول تشغيل ليلي لك

ابدأ صغيرًا. اختر سير عمل واحدًا حاسمًا، مثل تدفق تسجيل الدخول الخاص بك أو مسار الدفع، وقم ببنائه كسيناريو Apidog واحد مع تأكيدات حقيقية. قم بتشغيله محليًا باستخدام CLI حتى يصبح أخضر. ضع الأمر الذي تم إنشاؤه في مهمة مجدولة باستخدام أحد القوالب المذكورة أعلاه. اربط الفشل بدردشة فريقك. هذا هو بناء ليلي يعمل بشكل كامل في فترة ما بعد الظهر.

من هناك، قم بتوسيع المجموعة. أضف سيناريوهات للرحلات الأكثر أهمية التالية، وقم بتشغيل التحقق من المخطط عبر جميع الجوانب، وحدد ميزانيات الأداء على نقاط النهاية الهامة الخاصة بك. في غضون أسبوع، سيكون لديك شبكة انحدار تلتقط الإخفاقات التي لم تُصمم اختباراتك لكل التزام لرؤيتها أبدًا، وستسمع عنها من رسالة دردشة في الساعة 2 صباحًا بدلاً من عميل في الساعة 9.

زر التحميل