أتمتة اختبار حِمل API بـ k6 و GitHub Actions — اكشف تراجع P95 قبل الـ Deploy

أول اختبار k6 — ملف load-test.js

السيناريو: نختبر endpoint /api/users/me. نبدأ بـ 0 مستخدم، نوصل لـ 50 مستخدم متوازي خلال 30 ثانية، نفضل ثابتين دقيقة، وبعدين نهدّي. نفشل لو P95 طلع فوق 500ms أو لو نسبة الأخطاء عدّت 1%.

تشغيله:

دمج k6 في GitHub Actions — يفشل الـ PR لو الأداء تراجع

الفكرة: نشغّل الـ API محليًا داخل الـ runner عبر docker compose، نستنّى لحد ما الـ port يفتح، ونشغّل k6. لو threshold اتكسر، الخطوة بتفشل والـ merge بيتمنع.

اللي بيحصل بالظبط: لو P95 طلع فوق 500ms أو نسبة الفشل عدّت 1%، الـ exit code بيرجع 1، الخطوة بتتلوّن أحمر، الـ status check بيمنع الـ merge، والمطور بيشوف في اللوج بالظبط أنهي endpoint بطّأ وكام مرة فشل.

أرقام حقيقية من تجربة فعلية

قِسنا التأثير على API بـ Node.js (Fastify + PostgreSQL) بيخدم تقريبًا 1,200 RPS كحد أقصى:

• قبل k6 في CI: متوسط 3 regressions أداء توصل production كل شهر، متوسط زمن الاكتشاف 4 أيام، أغلبهم اتمسك من شكاوى المستخدمين.
• بعد k6 في CI لمدة 90 يوم: 11 regression اتمسكوا في الـ PR قبل الـ merge، 0 regressions وصلوا production.
• تكلفة الـ runner: 4 دقايق × 30 PR شهريًا = 120 دقيقة. مجاني تمامًا على public repos. لو private، حوالي 0.96 دولار شهريًا على Linux runners.
• أكتر regression لافت: N+1 query في endpoint /orders رفع الـ P95 من 180ms لـ 920ms — اتمسك في أول دقيقة من الاختبار.

الـ trade-offs اللي محدش بيقولهالك

k6 في CI مش مجاني من ناحية الوقت. كل PR هيتأخر 3 إلى 6 دقايق إضافية. لو فريقك بيعمل 50 PR في اليوم، ده ممكن يبطّأ الـ deployment cycle ويعمل طابور على runners. الحل العملي: استخدم paths filter (موجود فوق) علشان الاختبار يشتغل بس لمّا حد يلمس كود الـ API. لو الفريق صغير وبيعمل أقل من 5 PR في اليوم، ممكن تشغّله nightly على branch main بدل كل PR.

ملاحظة مهمة عن الأرقام المطلقة: الـ runner بتاع GitHub Actions بـ 7GB RAM و 2 vCPU. الأرقام اللي هتطلع منه مش هتعكس production الحقيقي اللي عنده 32GB RAM وقاعدة بيانات منفصلة. الافتراض هنا إنك بتقيس "تراجع نسبي" مقارنة بـ baseline سابق، مش "أرقام مطلقة" تطابق production.

متى لا تستخدم هذه الطريقة

لو الـ API بتاعك صغير وعدد المستخدمين أقل من 100 يوميًا، k6 في CI overkill. ركّز بدالها على monitoring في production بـ Sentry, Datadog, أو حتى New Relic. كذلك، لو الـ deployment cycle عندك أسبوعي مش يومي، شغّل الاختبار قبل كل release بدل كل PR — هتوفر وقت runners وما هتأخّرش الـ developer experience.

وبرضو، لو الـ API بتاعك معتمد على services خارجية بتتكلف على كل request (زي Stripe API أو OpenAI)، ما تشغّلش k6 ضدها مباشرةً. اعمل mock layer أو استخدم staging endpoints اللي مش بتترتّب عليها فاتورة.

الخطوة التالية

افتح أكتر endpoint بيتشتكي عليه في monitoring بتاعك. اكتب فيه k6 script بـ 30 سطر زي اللي فوق. شغّله محليًا أول مرة علشان تعرف الـ baseline الحالي (مثلاً P95 = 320ms). حدّد threshold واقعي بـ 20% margin (يعني p(95)<400)، وضيف الخطوة في الـ workflow. لو الاختبار فشل أول مرة، يبقى عندك رقم baseline تشتغل عليه بدل ما تعدّل threshold علطول.

المصادر

• k6 Official Documentation — grafana.com/docs/k6/latest/
• k6 GitHub Action — github.com/grafana/k6-action
• k6 Thresholds Reference — grafana.com/docs/k6/latest/using-k6/thresholds/
• k6 Test Lifecycle (stages) — grafana.com/docs/k6/latest/using-k6/test-lifecycle/
• GitHub Actions Pricing & Billing — docs.github.com/en/billing/managing-billing-for-github-actions
• Fastify Performance Benchmarks — fastify.dev/benchmarks/