في تطوير البرمجيات التعاوني، يمكن أن يصبح تشغيل اختبارات API يدويًا بعد كل تغيير في الكود أمرًا شاقًا بسرعة. ألن يكون أفضل لو أن هذه الاختبارات يمكن تشغيلها تلقائيًا كلما تم دفع كود جديد؟
الخبر السار هو أن هذا ممكن تمامًا. تستخدم معظم الفرق بالفعل منصات CI/CD للتعامل مع بناء ونشر الكود، وقد تم تصميم هذه المنصات للاستماع إلى أحداث Git commit. عندما تقوم بدفع الكود، فإنها تنفذ تلقائيًا مهامًا محددة مسبقًا مثل التجميع أو التعبئة أو النشر.
تشغيل اختبارات API الآلية لا يختلف. يوفر Apidog أداة سطر أوامر (CLI) تتيح لك تشغيل الاختبارات الآلية بأمر واحد. بإضافة هذا الأمر إلى مسار CI/CD الخاص بك، يمكنك ضمان تشغيل الاختبارات تلقائيًا بعد كل إرسال للكود.
عملية الإعداد مباشرة. الشيء الرئيسي الذي يجب فهمه هو كيفية عمل آلية التشغيل، ثم اختيار نهج التكامل الصحيح بناءً على المنصة التي يستخدمها فريقك.
كيف تعمل مشغلات الاختبار التلقائية؟ (المبادئ)
جوهر العملية برمتها هو "الاستماع إلى الأحداث + تنفيذ الأوامر".
عندما تقوم بدفع الكود إلى مستودع Git، تستمع منصة CI/CD إلى حدث Git هذا، ووفقًا لتكوينك المسبق (مثل نصوص البايبلاين أو ملفات التكوين)، تنفذ تلقائيًا أمر اختبار Apidog.
يمكن توضيح هذا المبدأ على النحو التالي:
هناك طريقتان رئيسيتان لمنصات CI/CD للاستماع إلى أحداث Git:
الأولى هي آلية الأحداث المدمجة في المنصة. على سبيل المثال، يمكن تحديد GitHub Actions مباشرة في ملف التكوين: on: [push, pull_request]. عندما تقوم بدفع الكود أو إنشاء طلب سحب (PR)، تستمع المنصة تلقائيًا إلى أحداث Git هذه وتبدأ الاختبار.
والثانية هي عبر Webhook، وهي مناسبة لسيناريوهات مثل Jenkins حيث تكون هناك حاجة للتواصل عبر المنصات. سيتعين عليك تكوين عنوان URL للمشغل يدويًا.
بغض النظر عن الطريقة، فإن الخطوة الأخيرة هي دائمًا نفسها: تنفيذ الأمر apidog run لبدء الاختبار الآلي.
حلول التكامل للمنصات الشائعة
إذا كنت تستخدم منصات استضافة الكود مثل GitHub أو GitLab، فإن تشغيل الاختبارات بسيط بشكل خاص. تحتوي هذه المنصات على خدمات CI/CD مدمجة (مثل GitHub Actions، GitLab CI) يمكنها الاستماع مباشرة إلى أحداث Git وتنفيذ المهام. يمكنك الرجوع إلى هذه الوثائق للبدء بسرعة:
ومع ذلك، فإن العديد من الفرق لديها إعدادات أكثر تعقيدًا. على سبيل المثال، يتم استضافة الكود على GitHub أو GitLab، ولكن مسار CI/CD يعمل على Jenkins. في هذه الحالة، GitHub/GitLab و Jenkins هما نظامان مستقلان - الأول لا يمكنه تشغيل الأخير مباشرة.
بالنسبة لسيناريوهات عبر المنصات، تعد Webhooks حلاً بسيطًا وفعالاً. يعمل Webhook كآلية رد اتصال - عندما يحدث حدث معين (مثل دفع Git) على GitHub، فإنه يرسل طلبًا نشطًا إلى عنوان URL لـ Webhook محدد مسبقًا لتنبيه نظام خارجي. من خلال تقديم نقطة نهاية Webhook، يمكن لـ Jenkins تلقي هذه الإشعارات وتشغيل مهام الاختبار تلقائيًا.
دعنا نلقي نظرة على تكوين محدد: يتم استضافة الكود على GitHub، ولكن مسار الاختبار يعمل على Jenkins.
تكامل GitHub + Jenkins لتشغيل اختبارات Apidog الآلية
إذا كان فريقك يخزن الكود على GitHub ولكنه يستخدم Jenkins لتشغيل مهام البناء، فإليك كيفية إعداده:
الخطوة 1: تكوين Jenkins والحصول على عنوان URL لـ Webhook
أولاً، قم بإعداد مهمة الاختبار في Jenkins. اتبع وثائق التكامل مع Jenkins لإنشاء مشروع، وتكوين أمر البناء، والتأكد من أن أمر CLI يمكن تشغيله بشكل صحيح.
بعد ذلك، احصل على عنوان URL لـ Webhook من Jenkins. يعمل عنوان URL هذا كنقطة دخول للأنظمة الخارجية لاستدعاء Jenkins، وسيستخدمه GitHub لتشغيل مهام الاختبار.
أبسط طريقة هي تثبيت مكون "Generic Webhook Trigger" الإضافي. ابحث عنه وقم بتثبيته في صفحة إدارة المكونات الإضافية في Jenkins، ثم أعد تشغيل Jenkins.
ثم انتقل إلى صفحة تكوين مشروعك وقم بتمكين هذا المكون الإضافي. سيكون عنوان Webhook:
http://<عنوان خادم Jenkins الخاص بك>/generic-webhook-trigger/invoke`
لأسباب أمنية، يوصى بتعيين رمز مميز مخصص (Token)، ليصبح العنوان:
http://<عنوان خادم Jenkins الخاص بك>/generic-webhook-trigger/invoke?token=<xxxxxx>بمجرد حصولك على عنوان URL هذا، يمكنك تكوين Webhook في GitHub.
الخطوة 2: تكوين Webhook في GitHub
انتقل إلى "مستودع GitHub الخاص بك ← الإعدادات ← Webhooks"، أضف Webhook جديدًا، أدخل العنوان من الخطوة السابقة، اضبط Content type على application/json، حدد الدفع (push) أو الأحداث الأخرى التي تريد تشغيل الاختبار بها، واحفظ التكوين.
بعد التكوين، سيؤدي كل دفع للكود إلى تشغيل Jenkins تلقائيًا لتنفيذ مهمة الاختبار. يمكنك دفع بعض الكود لاختباره والتحقق من سجلات بناء Jenkins ونتائج الاختبار.
الخطوة 3: التحقق من العملية بأكملها
عندما تدفع الكود إلى GitHub، سيرسل Webhook المكون إشعارًا إلى Jenkins. سيتلقى Jenkins الطلب ويبدأ مهمة البناء تلقائيًا. يمكنك رؤية سجلات تنفيذ الاختبار في "وحدة التحكم" بمشروع Jenkins ورؤية تقرير الاختبار النهائي.
تكوين Webhook لمنصات أخرى
بالإضافة إلى GitHub، تدعم منصات استضافة الكود الأخرى أيضًا Webhooks، مثل:
طرق التكوين متشابهة. المفتاح هو فهم آلية التشغيل: يقوم Git commit بتوليد حدث، والذي يستخدم بعد ذلك لإخطار منصة CI/CD عبر الاستماع إلى الأحداث أو Webhook، مما يؤدي في النهاية إلى التشغيل التلقائي لأمر الاختبار.
لمزيد من طرق تكامل منصات CI/CD، راجع قسم تكامل CI/CD في وثائق Apidog الرسمية.