كيفية تشغيل اختبارات API المؤتمتة في Azure Pipelines خطوة بخطوة

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

هذه الفجوة، بين "الاختبارات موجودة" و "الاختبارات تعمل مع كل تغيير"، هي بالضبط ما يسده مسار CI (التكامل المستمر). إذا كان رمزك موجودًا بالفعل في Azure Repos أو GitHub وفريقك يبني على Azure DevOps، فإن Azure Pipelines هو المكان الطبيعي لوضع شبكة الأمان هذه. الجزء الصعب نادرًا ما يكون ملف YAML. إنه تحويل مجموعة اختبارات الـ API الخاصة بك إلى شكل يمكن للمسار تشغيله بدون واجهة مستخدم (headless)، بالبيئة الصحيحة، مقابل بناء تم نشره حديثًا، ثم إفشال البناء بصوت عالٍ عندما يحدث خطأ ما.

ملخص سريع (TL;DR)

• يقوم Azure Pipelines بتشغيل اختبارات الـ API الخاصة بك تلقائيًا عند كل عملية commit أو طلب سحب (PR)، بحيث يتم اكتشاف الانحدارات قبل نشرها.
• أنشئ سيناريوهات الاختبار الخاصة بك بصريًا في Apidog، ثم قم بتشغيلها في CI باستخدام واجهة سطر الأوامر الخاصة بـ Apidog (apidog-cli) بدلاً من كتابة وصيانة نصوص الاختبار يدويًا.
• يحتاج المسار إلى أربعة أشياء: Node.js مثبت على الوكيل (agent)، واجهة سطر الأوامر مثبتة، سيناريو الاختبار الخاص بك يمكن الوصول إليه عبر رابط أو ملف مُصدّر، ورمز وصول (access token) مخزن كسِر.
• رمز خروج غير صفري من واجهة سطر الأوامر يفشل البناء تلقائيًا. هذا ما يمنحك بوابة حقيقية.
• انشر تقرير HTML أو JUnit كـ artifact للمسار (أو عبر PublishTestResults) حتى يتمكن أي شخص من قراءة النجاح/الفشل دون فتح السجلات.

ماذا يعني "الاختبار الآلي للـ API في Azure Pipelines" في الواقع

Azure Pipelines هي خدمة CI/CD داخل Azure DevOps. تقوم بوصف بناء (build) في ملف YAML (azure-pipelines.yml) الذي يعيش في مستودعك، ويقوم Azure بتشغيل هذا الملف على وكيل مستضاف (hosted) أو ذاتي الاستضافة (self-hosted) في كل مرة يتم فيها تشغيل محفّز (trigger)؛ دفعة (push)، طلب سحب (pull request)، جدول زمني، أو تشغيل يدوي.

بالنسبة لاختبار الـ API، المهمة واضحة الشكل:

1. تشغيل وكيل (آلة افتراضية نظيفة).
2. تثبيت كل ما يحتاجه مشغل الاختبار.
3. تشغيل اختبارات الـ API مقابل بيئة مستهدفة.
4. الإبلاغ عن النتائج وتعيين حالة البناء بناءً عليها.

التفصيل الذي يربك الناس هو الخطوة 3. عميل الـ API المحلي تفاعلي؛ تنقر على "إرسال"، وتلقي نظرة على الاستجابة، وتقرأ علامة صح خضراء. المسار ليس لديه من ينقر ولا من يلقي نظرة. أنت بحاجة إلى طريقة لتشغيل نفس التأكيدات (assertions) بدون إنسان وبدون واجهة رسومية. هذا هو السبب كله لوجود مشغل سطر الأوامر.

إذا كنت تريد مقدمة أوسع لمفاهيم CI هنا، فإن الفرق بين التكامل المستمر، التسليم المستمر، والنشر المستمر يستحق قراءة سريعة قبل إعداد أول مسار لك.

لماذا تصمم الاختبارات في Apidog وتشغلها باستخدام واجهة سطر الأوامر

يمكنك كتابة اختبارات الـ API في رمز برمجي خام. اختر لغة، واستخدم مكتبة HTTP وإطار عمل تأكيد (assertion framework)، وأنشئ يدوياً هياكل الطلبات (request bodies)، واحلل الاستجابات، وأدر رموز المصادقة (auth tokens)، وحافظ على كل ذلك متزامناً مع API يتغير كل sprint. تقوم الفرق بذلك. كما أنهم يقضون قدرًا غير متناسب من الوقت في صيانتها.

يتخذ Apidog مسارًا مختلفًا. أنت تبني سيناريوهات الاختبار بصريًا: قم بربط الطلبات معًا، ومرر البيانات من استجابة واحدة إلى الطلب التالي، وأضف التأكيدات على رموز الحالة (status codes)، والعناوين (headers)، وحقول JSON، وقم بتشغيل نفس السيناريو بصفوف متعددة من البيانات. لأن Apidog يحمل بالفعل تعريفات الـ API الخاصة بك، تظل الاختبارات قريبة من المواصفات. عندما يتغير المخطط (schema)، ترى الانحراف بدلاً من اكتشافه في بيئة الإنتاج.

الجزء الذي يربط هذا العمل البصري بـ CI هو واجهة سطر الأوامر لـ Apidog (Apidog CLI)، وهو مشغل سطر أوامر منشور على npm. يقوم بتنفيذ سيناريو اختبار محفوظ بدون واجهة رسومية (headlessly) ويخرج برمز حالة يعكس النتيجة: 0 إذا نجح كل شيء، وغير صفري إذا فشل أي تأكيد. رمز الخروج هذا هو العقد الذي يفهمه كل نظام CI. يقرأه Azure Pipelines ويقرر ما إذا كان البناء أخضر أو أحمر. أنت تصمم مرة واحدة في الواجهة الرسومية، ويتم تشغيل نفس السيناريو دون تغيير في المسار.

هذا هو نفس النموذج الذي يعمل مع GitHub Actions و GitLab CI و Jenkins. Azure Pipelines هو مجرد مضيف آخر لنفس أمر سطر الأوامر، مما يعني أن المعرفة تنتقل إذا قام فريقك بتغيير الأنظمة الأساسية في أي وقت.

المتطلبات الأساسية

قبل بناء المسار، قم بتجهيز هذه الأشياء:

• مشروع Apidog يحتوي على سيناريو اختبار واحد على الأقل. افتح قسم Test Scenarios، أنشئ سيناريو، أضف بعض الطلبات، وأرفق تأكيدات. قم بتشغيله مرة واحدة محليًا وتأكد من نجاحه. إذا كان متقلبًا على جهازك، فسيكون متقلبًا في CI.
• رمز وصول Apidog. تقوم واجهة سطر الأوامر بالمصادقة باستخدام رمز وصول شخصي من إعدادات حساب Apidog الخاص بك. تعامله ككلمة مرور؛ ستخزنه كسِر للمسار، وليس أبدًا في ملف YAML.
• مشروع Azure DevOps مع مستودع (repo). سيعيش ملف azure-pipelines.yml الخاص بك في جذر المستودع.
• إلمام بـ Node.js (خفيف). تعمل واجهة سطر الأوامر على Node، لذلك يحتاج الوكيل إلى تثبيت Node. الوكلاء المستضافون من Azure لديهم بالفعل؛ ستقوم فقط باختيار إصدار.
• بيئة مستهدفة يمكن الوصول إليها. يجب أن تصل اختباراتك إلى API قيد التشغيل؛ عنوان URL لبيئة تجريبية (staging)، نشر معاينة (preview deployment)، أو خدمة يبدأها المسار نفسه. قرر أيًا منها قبل كتابة المشغل.

ملاحظة سريعة حول الهدف الذي يجب اختباره. تشغيل المجموعة ضد بيئة الإنتاج في كل عملية commit محفوف بالمخاطر وغالبًا ما يكون مستحيلًا (لا تريد بيانات اختبار في بيئة الإنتاج). معظم الفرق توجه اختبارات CI إلى بيئة تجريبية (staging environment) أو نشر معاينة لكل فرع. بيئات Apidog تجعل هذا نظيفًا: احتفظ ببيئة Staging مع عنوان URL أساسي ومتغيرات خاصة بها، وأخبر واجهة سطر الأوامر أيًا منها تستخدم عند التشغيل.

الخطوة 1: اجعل سيناريو الاختبار الخاص بك قابلاً للتشغيل

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

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

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

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

في كلتا الحالتين، لاحظ أمر التشغيل الدقيق الذي يمنحك إياه Apidog. سيبدو قريبًا من هذا:

apidog run https://api.apidog.com/api/v1/test-scenarios/<scenario-id> \
 -t <access-token> \
 -e <environment-id>

الأعلام التي ستعتمد عليها أكثر:

• مرجع السيناريو (رابط عبر الإنترنت أو مسار ملف محلي)،
• -t / رمز الوصول للمصادقة،
• -e لتحديد البيئة التي يجب تشغيل الاختبارات عليها،
• خيار تقرير للتحكم في تنسيق الإخراج (نص CLI، HTML، أو ملخص يمكن قراءته آليًا)،
• عدد التكرارات عندما تريد أن يقوم السيناريو بالتكرار عبر مجموعة بيانات.

تأكد من أسماء الأعلام الدقيقة مقابل أمر التشغيل الذي يولده Apidog لسيناريو الخاص بك؛ يطبع المشغل الاستخدام مع apidog run --help. لا تخمن الأعلام؛ انسخ تلك التي يقدمها لك Apidog وقم بتحويل الأسرار إلى متغيرات.

الخطوة 2: تحقق من أن واجهة سطر الأوامر تعمل محليًا أولاً

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

تثبيت واجهة سطر الأوامر:

npm install -g apidog-cli

ثم قم بتشغيل السيناريو الخاص بك:

apidog run https://api.apidog.com/api/v1/test-scenarios/<scenario-id> \
 -t "$APIDOG_ACCESS_TOKEN" \
 -e "<staging-environment-id>"

أنت تتحقق من ثلاثة أشياء:

1. يكتمل الأمر ويطبع ملخص النجاح/الفشل.
2. يتطابق رمز الخروج مع النتيجة. قم بتشغيل echo $? مباشرة بعد؛ يجب أن يكون 0 عند النجاح وغير صفري عند الفشل.
3. تم حل البيئة بشكل صحيح؛ وصلت الطلبات إلى عنوان URL لبيئة التجريب الخاصة بك، وليس أي عنوان URL محلي متبقي.

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

الخطوة 3: إنشاء ملف Azure Pipelines YAML

أضف ملفًا باسم azure-pipelines.yml إلى جذر مستودعك. نقطة بداية كاملة وعملية لوكيل Ubuntu مستضاف:

trigger:
 branches:
 include:
 - main
 - develop

pr:
 branches:
 include:
 - main

pool:
 vmImage: ubuntu-latest

variables:
 NODE_VERSION: '20.x'

steps:
 - task: NodeTool@0
 inputs:
 versionSpec: $(NODE_VERSION)
 displayName: 'Install Node.js'

 - script: npm install -g apidog-cli
 displayName: 'Install Apidog CLI'

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID)
 displayName: 'Run API tests'

شرح تفصيلي:

• trigger يقوم بتشغيل المسار في كل عملية push إلى main و develop. قم بتعديله ليناسب أسماء فروعك.
• pr يقوم بتشغيله على طلبات السحب التي تستهدف main. هذه هي البوابة التي تمنع دمج فرع معطل.
• pool / vmImage يختار وكيل Ubuntu مستضاف من Microsoft. لا توجد بنية تحتية لإدارتها.
• NodeTool@0 يثبت إصدار Node محدد، لذلك تكون عمليات التشغيل الخاصة بك قابلة لإعادة الإنتاج.
• خطوة التثبيت تسحب واجهة سطر الأوامر حديثًا في كل تشغيل. للبناءات الأسرع، يمكنك تخزين node_modules مؤقتًا أو تثبيت إصدار، ولكن ابدأ ببساطة.
• خطوة التشغيل هي الأهم. إذا فشل أي تأكيد، تخرج apidog run برمز غير صفري، تفشل مهمة السكريبت، ويتحول البناء بأكمله إلى اللون الأحمر.

المراجع $(...) هي متغيرات المسار. SCENARIO_ID، STAGING_ENV_ID، وخاصة APIDOG_ACCESS_TOKEN تأتي من الخطوة التالية، ولا يتم ترميزها هنا.

الخطوة 4: تخزين الأسرار بالطريقة الصحيحة

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

استخدم متغير مسار سري:

1. في Azure DevOps، افتح المسار الخاص بك واختر Edit، ثم Variables (أو Library لمجموعة متغيرات مشتركة).
2. أضف APIDOG_ACCESS_TOKEN والصق الرمز.
3. قم بتبديل أيقونة القفل لتمييزه كسِر. يقوم Azure بتشفيره وإخفائه في السجلات.

لا يتم حقن المتغيرات السرية في بيئة Shell تلقائيًا؛ يجب أن تقوم بتعيينها صراحةً في الخطوة. قم بتحديث خطوة التشغيل لتمرير السر عبر env:

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID)
 displayName: 'Run API tests'
 env:
 APIDOG_ACCESS_TOKEN: $(APIDOG_ACCESS_TOKEN)

لا تحتاج SCENARIO_ID و STAGING_ENV_ID إلى أن تكون سرية؛ تعامل معهما كمتغيرات عادية لسهولة القراءة، أو انقلها إلى مجموعة متغيرات تعيد استخدامها عبر المسارات. بالنسبة للفرق التي تدير العديد من الأسرار، قم بدعم مجموعة المتغيرات باستخدام Azure Key Vault بحيث يتم تدويرها في مكان واحد.

الخطوة 5: نشر تقرير اختبار قابل للقراءة

البناء الأحمر يخبرك أن شيئًا ما انكسر. لكنه لا يخبرك ما هو. الحل هو أن تقوم واجهة سطر الأوامر بإصدار تقرير وأن تقوم Azure بإظهاره.

يمكن لـ Apidog CLI كتابة نتائجه إلى ملف تقرير. وجهه إلى تنسيق إخراج (HTML للبشر، XML بنمط JUnit إذا كنت تريد عرض اختبارات Azure الأصلي) ودليل إخراج، ثم انشر هذا الدليل.

للحصول على artifact قابل للقراءة بشريًا:

 - script: |
 apidog run https://api.apidog.com/api/v1/test-scenarios/$(SCENARIO_ID) \
 -t $(APIDOG_ACCESS_TOKEN) \
 -e $(STAGING_ENV_ID) \
 -r html \
 --out-dir $(Build.ArtifactStagingDirectory)/api-report
 displayName: 'Run API tests'
 env:
 APIDOG_ACCESS_TOKEN: $(APIDOG_ACCESS_TOKEN)

 - task: PublishBuildArtifacts@1
 condition: always()
 inputs:
 pathToPublish: $(Build.ArtifactStagingDirectory)/api-report
 artifactName: api-test-report
 displayName: 'Publish API test report'

هناك شيئان يجب ملاحظتهما. أولاً، condition: always() يجعل خطوة النشر تعمل حتى عندما تفشل خطوة الاختبار؛ وهذا هو الهدف الرئيسي، حيث أنك تريد التقرير أكثر عندما يحدث خطأ ما. ثانيًا، تحقق من علامة المراسل الدقيقة (-r أو --reporter أو ما شابه) وخيار الإخراج مقابل apidog run --help لإصدار واجهة سطر الأوامر الخاص بك، ثم اضبط المثال ليطابق.

إذا كنت تفضل رؤية النتائج في علامة التبويب "Tests" المضمنة في Azure مع رسوم بيانية للاتجاهات، فاجعل واجهة سطر الأوامر تصدر JUnit XML وأضف مهمة PublishTestResults@2 تشير إلى ملف XML. يمنحك ذلك سجلًا لكل تأكيد عبر البناءات، وليس مجرد ملف لمرة واحدة.

الخطوة 6: اجعل البوابة حقيقية

إعداد المسار ليس هو نفسه فرضه. بشكل افتراضي، البناء الفاشل لا يمنع أي شخص من الدمج ما لم تخبر Azure DevOps بطلب ذلك.

قم بإعداد سياسة فرع على main:

1. اذهب إلى Repos، ثم Branches، ابحث عن main، وافتح Branch policies.
2. أضف Build Validation وحدد المسار الخاص بك.
3. اجعله مطلوبًا.

الآن لا يمكن لطلب السحب الدمج في main حتى ينجح مسار اختبار الـ API. هذا هو الفرق بين الاختبارات التي تعمل والاختبارات التي تحمي. حتى تقوم بتشغيل هذا، لديك لوحة تحكم؛ بعد ذلك، لديك بوابة.

مثال واقعي يعتمد على البيانات

سيناريوهات الطلقة الواحدة (Single-shot) تكتشف الأعطال الواضحة. تتطلب واجهات الـ API الحقيقية تشغيل نفس نقطة النهاية بالعديد من المدخلات؛ حمولات صالحة، حالات حافة، الطلب المشوه الذي يجب أن يعيد 400 بدلاً من 500.

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

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

مشاكل شائعة وكيفية إصلاحها

البناء ينجح على الرغم من أن نقطة نهاية معطلة. غالبًا ما تكون مشكلة في رمز الخروج. تأكد من أن CLI يعيد قيمة غير صفرية عند الفشل (الخطوة 2)، وتأكد من أنك لا تبتلعها؛ || true في النهاية أو سكريبت متعدد الأوامر ينتهي بأمر مختلف سيخفي الفشل. اجعل استدعاء apidog run هو آخر أمر ذي معنى في كتلة السكريبت الخاصة به.

apidog: command not found. خطوة التثبيت لم تعمل، أو عملت بعد خطوة الاختبار، أو تم التثبيت في مسار لا يمكن لـ shell الخاص بالوكيل رؤيته. تأكد من ظهور npm install -g apidog-cli قبل خطوة التشغيل. على بعض الوكلاء ذاتيي الاستضافة، قد لا يكون مجلد npm العام في PATH؛ قم بالتثبيت محليًا واستدعه عبر npx apidog run ... بدلاً من ذلك.

فشل المصادقة في CI ولكنه يعمل محليًا. السر لا يصل إلى الخطوة. يجب تعيين المتغيرات السرية عبر env: (الخطوة 4)؛ لا يتم حقنها تلقائيًا. تحقق أيضًا من أن الرمز لم يتم لصقه مع سطر جديد زائد أو علامة اقتباس.

الاختبارات تضرب البيئة الخاطئة. قيمة -e تشير إلى بيئة Apidog خاطئة، أو أن عنوان URL الأساسي للبيئة لا يزال يشير إلى localhost. احتفظ ببيئة Staging مخصصة لـ CI تكون متغيراتها تُحل إلى عناوين URL آمنة ويمكن الوصول إليها عبر CI، ومرر معرفها صراحةً.

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

ما وراء الأساسيات

بمجرد أن يصبح المسار الأساسي صلبًا، فإن بعض الإضافات تؤتي ثمارها:

• جدولة تشغيل ليلي. أضف مشغل schedules لتشغيل المجموعة الكاملة في الساعة 2 صباحًا مقابل بيئة التجريب (staging)، بحيث تكتشف الانحراف الناتج عن تغييرات البيانات أو تحولات API للجهات الخارجية حتى في الأيام التي لا يقوم فيها أحد بنشر رمز.
• فصل المجموعات السريعة والبطيئة. قم بتشغيل سيناريو اختبار سريع (smoke scenario) في كل طلب سحب (PR) للحصول على ملاحظات سريعة، ومجموعة اختبارات الانحدار الكاملة (full regression suite) عند الدمج في main. تعريفان للمسار، نفس CLI.
• اختبار بيئات متعددة في مصفوفة. استخدم مصفوفة المسار لتشغيل نفس السيناريو مقابل بيئة التجريب وبيئة ما قبل الإنتاج بالتوازي، كل واحدة بمعرف بيئة خاص بها.
• فرض البوابة على النشر، وليس فقط الدمج. ضع مرحلة اختبار الـ API قبل مرحلة النشر في مسار متعدد المراحل، بحيث يؤدي الاختبار الفاشل إلى إيقاف الإصدار، وليس فقط الدمج.

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

أسئلة مكررة

هل أحتاج إلى كتابة أي رمز لتشغيل اختبارات API في Azure Pipelines؟ لا. أنت تبني سيناريوهات الاختبار بصريًا في Apidog ويقوم المسار بتشغيلها بأمر CLI واحد. "الرمز" الوحيد هو ملف azure-pipelines.yml نفسه، وهو عبارة عن تهيئة، وليس منطق اختبار. إذا كنت تفضل اختبارات تعتمد على السكريبت بالكامل، فلا يزال بإمكانك فعل ذلك، ولكن الهدف من سير العمل هذا هو تخطيه.

هل يمكنني تشغيل مجموعات Postman الموجودة لدي في Azure Pipelines بدلاً من ذلك؟ يمكنك ذلك، عادةً باستخدام Newman أو مشغل مشابه. إذا كنت تقارن بين الخيارات، فإن Apidog يستورد مجموعات Postman مباشرةً، بحيث يمكنك جلب الاختبارات الموجودة وتشغيلها من خلال نفس CLI دون الحاجة إلى صيانة سلسلة أدوات منفصلة. راجع كيفية تشغيل اختبارات API في CI بدون Newman للمقارنة.

إلى أين يجب أن تشير الاختبارات؛ بيئة التجريب أم الإنتاج؟ بيئة التجريب (staging) أو بيئة معاينة لكل فرع، دائمًا تقريبًا. تشغيل اختبارات كثيرة الكتابة مقابل بيئة الإنتاج يلوث البيانات الحقيقية ويمكن أن يؤدي إلى آثار جانبية حقيقية. احتفظ ببيئة Apidog مخصصة لـ CI مع عناوين URL أساسية آمنة، ومرر معرفها إلى CLI باستخدام -e.

كيف يعرف المسار أن الاختبار فشل؟ من خلال رمز الخروج. تُرجع apidog run القيمة 0 عندما تنجح جميع التأكيدات ورمزًا غير صفري عندما يفشل أي منها. يقوم Azure Pipelines بفشل مهمة السكريبت عند خروج غير صفري، مما يؤدي إلى فشل البناء. تحقق من ذلك مرة واحدة محليًا باستخدام echo $? لتتأكد من البوابة.

هل يعمل هذا مع مسارات Azure DevOps Classic (UI) فقط، وليس فقط YAML؟ نعم. تنطبق نفس الخطوات؛ أضف مهمة "Use Node"، ومهمة سطر أوامر تقوم بتشغيل npm install -g apidog-cli، ومهمة سطر أوامر أخرى تقوم بتشغيل apidog run .... يوصى باستخدام YAML لأنه يعيش في مستودعك ويتم التحكم في إصداراته، لكن المشغل لا يهتم بكيفية تعريف الخطوات.

هل يمكنني استخدام وكيل ذاتي الاستضافة بدلاً من وكيل مستضاف من Microsoft؟ نعم. تعمل الوكلاء ذاتيو الاستضافة بنفس الطريقة؛ فقط تأكد من تثبيت Node.js وأن مجلد npm العام موجود في PATH الخاص بالوكيل، أو استدعِ CLI عبر npx. تعتبر الوكلاء ذاتيو الاستضافة مفيدًا عندما يكون API التجريبي الخاص بك قابلاً للوصول فقط من داخل شبكة خاصة.

خاتمة

يجب أن يعني بناء CI الأخضر أن واجهة برمجة التطبيقات (API) الخاصة بك تعمل بالفعل، وليس فقط أن الكود قد تم تجميعه. الوصول إلى ذلك في Azure Pipelines يعتمد على أربع خطوات: تصميم سيناريوهات اختبار حقيقية في Apidog، تشغيلها بدون واجهة مستخدم (headlessly) باستخدام Apidog CLI، ترك رمز الخروج يتحكم في حالة البناء، وطلب نجاح البناء قبل دمج أي شيء. بمجرد أن تعمل هذه الحلقة، يحصل كل دفع (push) على نفس التدقيق الذي سيقدمه زميلك الأكثر حذرًا، تلقائيًا، في كل مرة.

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

هل أنت مستعد لإعدادها؟ قم بتنزيل Apidog، وأنشئ سيناريو اختبار، واحصل على أمر تشغيل CLI، وضعه في ملف azure-pipelines.yml الخاص بك. سيتم اكتشاف الانحدار التالي بواسطة جهاز بدلاً من عميل.