النشر الأزرق-الأخضر لواجهات برمجة التطبيقات (APIs): دليلك للاختبار قبل التفعيل

نشر الأزرق-الأخضر (Blue-green deployment) يعد بإصدارات بدون توقف للخدمة: تقوم بتشغيل نسخة جديدة من خدمتك، وترسل إليها بعض حركة المرور، ثم تتحول إليها بمجرد أن تبدو سليمة. المشكلة تكمن في كلمة "سليمة". عادةً ما يقوم فحص سلامة موازن التحميل (load balancer) بإرسال طلب (ping) إلى نقطة نهاية واحدة وينتظر استجابة 200. هذا يخبرك أن العملية تعمل. لكنه لا يخبرك شيئًا عما إذا كانت النسخة الجديدة تعيد JSON الصحيح، أو تلتزم بنفس العقد، أو ما زالت تصادق على رمز مميز (token) بالطريقة التي كانت عليها النسخة القديمة. لذا تقوم بالتبديل، ويجد أول مستخدم حقيقي الخلل الذي لم يتمكن فحص سلامتك من رؤيته.

يرشدك هذا الدليل إلى كيفية اختبار البيئة الخضراء (green environment) كما لو كنت مستخدمًا قبل وصول أي حركة مرور إنتاج إليها. ستُشغل مجموعة كاملة من اختبارات API مقابل المكدس الخامل، وتُقيِّد عملية التحويل بتلك النتائج، وتُدمج كل ذلك في خط أنابيبك ليحدث في كل عملية نشر. سنستخدم Apidog وواجهة سطر الأوامر (CLI) الخاصة به كطبقة اختبار، لأن نفس سيناريوهات الاختبار التي تبنيها في تطبيق سطح المكتب يمكن تشغيلها تلقائيًا في التكامل المستمر (CI) ضد أي بيئة توجهها إليها.

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

خلاصة القول (TL;DR)

نشر الأزرق-الأخضر يدير بيئتي إنتاج متطابقتين ويحول موجه حركة المرور بينهما. قبل تحويل حركة المرور من الأزرق (الفعال) إلى الأخضر (الجديد)، قم بتشغيل مجموعة اختبارات API الكاملة الخاصة بك مباشرةً ضد البيئة الخضراء. اجعل عملية التحويل مشروطة بنجاح بناء البيئة الخضراء لمجموعة الاختبار. باستخدام Apidog CLI، وجه نفس سيناريوهات الاختبار إلى عنوان URL الأساسي للبيئة الخضراء في خط أنابيبك، أفشل النشر إذا فشل أي تأكيد (assertion)، وعندها فقط قم بتحويل الموجه. تؤكد فحوصات السلامة أن العملية تعمل؛ وتؤكد اختبارات API أن العقد لا يزال ساريًا.

ما هو نشر الأزرق-الأخضر بالفعل

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

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

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

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

لماذا فحص السلامة ليس اختبارًا

هذه هي الفجوة التي تضر الفرق. يبدو فحص السلامة النموذجي كالتالي:

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

عادةً ما تُرجع نقطة النهاية هذه {"status":"ok"} مكتوبة بشكل ثابت. إنها لا تصل إلى قاعدة بياناتك. إنها لا تمارس عملية المصادقة. إنها لا تُسلسِل موردًا حقيقيًا. يمكن أن يجتاز بناء (build) هذا الفحص بينما تُرجع كل نقطة نهاية أعمال استجابة 500، أو حمولة غير صحيحة، أو مخطط بيانات الأمس.

فكر في أنماط الفشل التي سيمررها فحص /health بسعادة:

تغيير في قاعدة البيانات لم يتم تنفيذه (migration)، مما يجعل GET /orders/{id} يعطي خطأ بسبب عمود مفقود.
حقل JSON تم تغيير اسمه (أصبح userId بدلاً من user_id) مما يعطل كل المستهلكين التابعين.
تغيير في المصادقة يرفض الآن الرموز المميزة التي لا يزال تطبيق الجوال يصدرها.
تحديث إصدار تبعية يغير تنسيق التاريخ من ISO 8601 إلى طابع زمني Unix.
رأس (header) جديد مطلوب يُرجع 400 لأي عميل لا يرسله.

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

سير عمل اختبار الأزرق-الأخضر، من البداية إلى النهاية

هذا هو التسلسل الذي نعمل على بنائه. الخطوة الجديدة هي "اختبار البيئة الخضراء"، وتقع بين النشر والتبديل.

النشر إلى البيئة الخضراء. قم بدفع البناء الجديد إلى البيئة الخاملة. يصبح متاحًا على عنوان داخلي، على سبيل المثال https://green.internal.example.com، ولكن لا تصل إليه حركة مرور عامة بعد.
اختبار الضبابية (Smoke test) للبيئة الخضراء. قم بتشغيل مجموعة فرعية سريعة من طلبات المسار الحرج ضد البيئة الخضراء. تسجيل الدخول، جلب مورد أساسي، إنشاء مورد. إذا فشل أي منها، توقف هنا. لا تزال البيئة الزرقاء تخدم المستخدمين ولم يلاحظ أحد.
تشغيل المجموعة الكاملة ضد البيئة الخضراء. قم بتنفيذ سيناريوهات اختبار API الكاملة الخاصة بك (المسارات السعيدة، حالات الخطأ، تدفقات المصادقة، تأكيدات المخطط) موجهة إلى عنوان URL الأساسي للبيئة الخضراء.
تقييد التحويل. إذا نجحت المجموعة، تابع. إذا فشل أي شيء، يتوقف خط الأنابيب ويتم إزالة البيئة الخضراء أو تركها للفحص. الإنتاج لا يتأثر.
قلب المفتاح. أعد توجيه الموجه (موازن التحميل، DNS، أو محدد الخدمة) من البيئة الزرقاء إلى الخضراء.
التحقق في الإنتاج. قم بتشغيل نفس اختبار الضبابية ضد عنوان URL المباشر بعد التحويل للتأكد من أن التبديل تم بشكل نظيف.
الحفاظ على البيئة الزرقاء جاهزة. احتفظ بالبيئة القديمة لفترة تراجع (rollback). إذا انحرف المراقبة بعد التبديل، ارجع فورًا.

الخدعة هي أن الخطوات 2 و 3 و 6 تستخدم نفس تعريفات الاختبار. تقوم ببناء السيناريوهات مرة واحدة وتغيير عنوان URL الأساسي الذي يستهدفه المشغل فقط. هذه هي القدرة التي سنقوم بإعدادها لاحقًا.

بناء سيناريوهات الاختبار في Apidog

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

داخل المشروع، تقوم بتجميع سيناريوهات الاختبار من نقاط نهاية API الموجودة لديك. السيناريو هو مجموعة مرتبة من الطلبات مع تأكيدات وتمرير للمتغيرات بين الخطوات. بالنسبة لمجموعة جاهزية الأزرق-الأخضر، تريد سيناريوهات تعكس ما يفعله العملاء الحقيقيون، وليس مجرد طلبات فردية (pings).

مجموعة بداية عملية لخدمة الطلبات:

تدفق المصادقة: POST /auth/login باستخدام بيانات اعتماد صالحة، تأكيد 200، استخراج رمز المصدق (bearer token) إلى متغير، ثم استخدامه في كل طلب لاحق.
مسار القراءة: GET /orders مع الرمز، تأكيد 200، تأكيد أن الاستجابة هي مصفوفة، تأكيد أن كل عنصر يحتوي على id وstatus وtotal.
مورد واحد: GET /orders/{id}، تأكيد أن المخطط يطابق تعريف OpenAPI الخاص بك، تأكيد أن total هو رقم أكبر من الصفر.
مسار الكتابة: POST /orders مع نص صالح، تأكيد 201، تأكيد أن id المُرجع غير فارغ، ثم GET لهذا المعرف الجديد مرة أخرى لتأكيد استمراره.
الحالات السلبية: GET /orders/{id} باستخدام رمز غير صالح، تأكيد 401. POST /orders مع حقل مطلوب مفقود، تأكيد 400.

هناك ميزتان تهمان أكثر لاكتشاف الأعطال التي يفوتها فحص السلامة. أولاً، تأكيدات المخطط (schema assertions): يمكن لـ Apidog التحقق من صحة الاستجابة مقابل مخطط JSON أو تعريف OpenAPI لنقطة النهاية هذه، لذا فإن الحقل الذي تم تغيير اسمه أو إعادة نوعه يفشل الاختبار بدلاً من أن يتسلل إلى الإنتاج. ثانيًا، تأكيدات الاستجابة (response assertions) على قيم محددة، ورؤوس الطلبات، ووقت الاستجابة، بحيث تلتقط التغيرات الدقيقة: تغيير تنسيق التاريخ، قيمة null حيث كنت تتوقع رقمًا، تراجع في زمن الاستجابة.

القرار التصميمي الرئيسي هو التعامل مع البيئات. لا تكتب https://blue.example.com مباشرةً في طلباتك. عرّف متغير بيئة لعنوان URL الأساسي وارجع إليه في كل مكان باسم {{baseUrl}}. في Apidog، تقوم بإعداد بيئات (الإنتاج، الخضراء، المحلية) وتبديل البيئة النشطة، أو يمكنك تجاوز عنوان URL الأساسي في وقت التشغيل من واجهة سطر الأوامر (CLI). هذا هو نفس مبدأ التعامل مع البيئات والأسرار الذي تمت تغطيته في دليلنا حول عميل API مع إدارة البيئة والأسرار؛ تظل اختباراتك متطابقة بين البيئة الزرقاء والخضراء، يتغير فقط الهدف.

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

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

تطبيق سطح المكتب هو المكان الذي تبني فيه السيناريوهات وتصححها. واجهة سطر الأوامر (CLI) هي ما يشغلها في خط أنابيبك ضد البيئة الخضراء. قم بتثبيته باستخدام npm؛ تحتاج إلى Node.js v16 أو أحدث:

npm install -g apidog-cli

يقوم المشغل بتنفيذ سيناريو اختبار من تكوين التكامل المستمر (CI). في Apidog، تقوم بإنشاء تكوين CI لسيناريو اختبار، مما يمنحك أمر تشغيل مرتبطًا برمز وصول (access token). الشكل الأساسي:

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 تكتب تقريرًا مستقلاً يمكنك أرشفته كمنتج بناء (build artifact) لأي شخص يراجع عملية النشر. يوجد أيضًا أداة إعداد تقارير JSON عندما تريد تغذية النتائج إلى أداة أخرى. العلامة --out-file تسمي المخرجات بحيث يمكن تتبع كل تشغيل إلى بناء (build).

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

# اختبار البيئة الخضراء (الخاملة) قبل التحويل
apidog run "<ci-config-url>" \
  --environment <greenEnvironmentId> \
  -r cli,html \
  --out-file green-pre-switch

يمكنك أيضًا تشغيل الاختبارات بالكامل من ملفات السيناريو المصدرة عندما تفضل الاحتفاظ بكل شيء في المستودع وتجنب استدعاء شبكة لجلب التكوين:

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

لجولة أعمق في المشغل وخياراته في سياق خط الأنابيب، راجع كيفية أتمتة اختبارات API في CI/CD. السلوك الذي يهم في نشر الأزرق-الأخضر هو رمز الخروج: عندما يفشل تأكيد (assertion)، تخرج واجهة سطر الأوامر (CLI) بقيمة غير صفرية. هذه الحقيقة الوحيدة هي ما يسمح لك بتقييد عملية التحويل. يوقف الخروج غير الصفري خط الأنابيب قبل أن يتم تشغيل خطوة التبديل على الإطلاق.

ربطه بخط أنابيب GitHub Actions

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

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
      # البيئة الخضراء الآن يمكن الوصول إليها عبر 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        # لا يتم التشغيل إلا إذا نجح اختبار البيئة الخضراء
    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 كأسرار للمستودع، لا تضعهما مباشرةً. يمكن أن تكون معرّفات البيئة كمتغيرات للمستودع لأنها ليست حساسة. إذا كان فريقك يعمل على GitLab أو Jenkins أو CircleCI أو Azure Pipelines، فإن الهيكل متطابق: مرحلة اختبار تخرج بقيمة غير صفرية تحظر مرحلة التبديل. يغطي دليلنا حول أتمتة اختبارات API في GitHub Actions إعداد المشغل بتفاصيل أكثر، وينتقل نفس النمط إلى أي من هذه المنصات.

اختبار الضبابية أولاً، المجموعة الكاملة ثانيًا

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

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

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

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

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

الأخطاء الشائعة التي تقوض الهدف بأكمله

تعتمد الفرق نشر الأزرق-الأخضر وما زالت ترسل الأعطال. عادة ما يكون أحد هذه الأسباب.

اختبار البيئة الزرقاء بدلاً من الخضراء. إذا كانت مجموعتك تشير إلى عنوان URL المباشر، فأنت تختبر الإصدار الموجود بالفعل في الإنتاج، وليس الإصدار الذي أنت على وشك إصداره. استهدف دائمًا عنوان URL الأساسي للبيئة الخضراء صراحةً قبل التبديل.
التحقق من رموز الحالة فقط. استجابة 200 مع نص خاطئ لا تزال استجابة معطلة. أكّد على شكل الحمولة والقيم الرئيسية، وليس فقط حالة HTTP. تأكيدات المخطط هي ما يلتقط تغييرات اسم الحقل وتغييرات النوع.
تجاهل الحالات السلبية. بناء (build) يُرجع 200 لرمز غير صالح هو تراجع أمني لن يكتشفه اختبار المسار السعيد أبدًا. قم بتضمين حالات 401 و403 و400 في الحاجز.
لا يوجد انضباط في التراجع. القوة الخارقة لنشر الأزرق-الأخضر هي التراجع الفوري، ولكن فقط إذا أبقيت البيئة الزرقاء جاهزة. لا تقم بإزالتها بمجرد أن تصبح البيئة الخضراء مباشرة. احتفظ بها خلال فترة المراقبة الخاصة بك.
عناوين URL مكتوبة مباشرة في طلبات الاختبار. في اللحظة التي يتم فيها تضمين عنوان URL أساسي في الطلب، تفقد القدرة على تشغيل نفس المجموعة ضد البيئتين الخضراء والزرقاء. استخدم متغير بيئة للمضيف، في كل مرة.
التعامل مع فحص السلامة كحاجز. هذه هي خلاصة المقال كله في سطر واحد. الفحص يخبر موازن التحميل أن عملية ما موجودة. اختبارات API الخاصة بك تخبرك أن العقد لا يزال ساريًا.

الأزرق-الأخضر مقابل الكناري: أين يقع الاختبار

نشر الأزرق-الأخضر ليس الاستراتيجية الوحيدة بدون توقف للخدمة، ويتغير نهج الاختبار مع كل منها.

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

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

الشكل الحقيقي لهذا في العالم الواقعي

يستخدم فريق تكنولوجيا مالية يدير واجهة برمجة تطبيقات للمدفوعات (API) نشر الأزرق-الأخضر لكل إصدار لأن النشر السيئ ليس مجرد خطأ تجميلي، بل هو معاملة فاشلة. حاجزهم هو مجموعة من أربعين سيناريو ضد البيئة الخضراء تغطي المصادقة، ومفاتيح الثبات (idempotency keys)، وتقريب العملة، وتوقيعات الويب هوك (webhook signatures). يستغرق التشغيل الكامل حوالي ست دقائق. لا يصل أي شيء إلى الإنتاج حتى يكون "أخضر" بالكامل، ويرفق تقرير HTML بكل عملية نشر لمسار التدقيق.

يدير فريق SaaS مع واجهة برمجة تطبيقات عامة (API) نسخة أكثر بساطة: حاجز ضبابية من اثني عشر سيناريو ضد البيئة الخضراء، ثم التبديل، ثم اختبار ضبابية بعد التحويل ضد عنوان URL المباشر. أولويتهم هي اكتشاف انحراف المخطط، حيث أن تكاملات الجهات الخارجية تتعطل بشكل كبير عندما يتغير شكل الحقل. تأكيدات المخطط على كل استجابة هي جوهر حاجزهم.

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

الخاتمة

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

العناصر:

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

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

button

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

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

كيف أختبر البيئة الخضراء قبل تحويل حركة المرور؟ وجه مجموعة اختبارات API الخاصة بك إلى عنوان URL الأساسي للبيئة الخضراء وقم بتشغيلها في خط أنابيبك قبل خطوة التحويل. باستخدام Apidog CLI، قم بتشغيل سيناريوهاتك باستخدام apidog run ضد البيئة الخضراء، أفشل النشر في حالة فشل أي تأكيد، وقم بتحويل حركة المرور فقط إذا نجحت المجموعة.

لماذا لا يكفي فحص سلامة موازن التحميل لنشر الأزرق-الأخضر؟ عادةً ما يقوم فحص السلامة بإرسال طلب (ping) إلى نقطة نهاية واحدة ويؤكد استجابة 200، وهذا يثبت فقط أن العملية تعمل. لن يكتشف حقل JSON تم تغيير اسمه، أو ترحيل فاشل (failed migration)، أو تدفق مصادقة معطل، أو تغيير في المخطط. تؤكد مجموعة اختبارات API الحقيقية على نصوص الاستجابة، والمخططات، وحالات الخطأ، لذا فهي تلتقط الأعطال التي يمررها فحص السلامة.

هل يمكنني تشغيل نفس اختبارات API في CI التي بنيتها في تطبيق سطح المكتب؟ نعم. تعمل السيناريوهات التي تبنيها بصريًا في Apidog دون تغيير من Apidog CLI. تقوم بإنشاء تكوين CI لسيناريو، ثم تستدعي apidog run بهذا التكوين في GitHub Actions، أو GitLab CI، أو Jenkins، أو أي خط أنابيب آخر. تخرج واجهة سطر الأوامر (CLI) بقيمة غير صفرية عند الفشل، مما يسمح لك بتقييد عملية النشر.

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

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

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