كيفية تشغيل اختبارات الـ API المؤتمتة في Bamboo CI خطوة بخطوة

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

هذه هي الفجوة التي تعاني منها معظم مسارات تكامل Bamboo المستمر (CI). يتميز Atlassian Bamboo بكونه جيدًا في تجميع الأكواد، وتشغيل مجموعات JUnit، وشحن الآثار. ما لا يفعله بنفسه هو التحقق من أن نقاط نهاية HTTP الخاصة بك لا تزال تتصرف بالطريقة التي يعد بها عقدك. إذا كنت تريد شبكة الأمان هذه، فعليك إضافة اختبارات API آلية كمرحلة في المسار. يشرح هذا الدليل بالتفصيل كيفية القيام بذلك، باستخدام Apidog لبناء الاختبارات وواجهة سطر الأوامر (CLI) الخاصة بـ Apidog لتشغيلها داخل مهمة Bamboo.

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

لماذا تنتمي اختبارات API إلى Bamboo، وليس بعده

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

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

• تنكسر العقود بصمت. يغير مطور الواجهة الخلفية اسم حقل JSON من userId إلى user_id. لا تزال اختبارات الوحدات تمر لأنها تختبر الوظيفة، وليس تنسيق الاتصال. يكتشف فريق الهاتف المحمول ذلك بعد ثلاثة أيام. يلتقط اختبار API الذي يؤكد على نص الاستجابة ذلك في نفس البناء الذي قدمه.
• تكذب رموز الحالة عندما لا يراقب أحد. نقطة نهاية كان من المفترض أن تعيد 201 Created تبدأ في إعادة 200 OK بعد إعادة هيكلة. وظيفيًا قريب، لكنه خاطئ تقنيًا، وسيرفضه العميل الصارم. يعلم تأكيد المسار بذلك في ثوانٍ.
• انحدارات المصادقة مكلفة. خطأ في تكوين تدفق تحديث الرمز المميز الذي يعيد 401 على بيانات اعتماد صالحة هو نوع من الأخطاء التي تعطل شاشة تسجيل الدخول. تشغيل طلب مصادق عليه في كل بناء يعني أنك تجده قبل أن يفعله المستخدمون.
• تتغير البيئات. تحصل بيئة التطوير على تغيير في التكوين، يتغير مفتاح ميزة، يتم ترقية تبعية. تشغيل نفس مجموعة API ضد بيئة التطوير بعد كل نشر يخبرك فورًا ما إذا كانت البيئة لا تزال صحية.

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

كيف يتناسب اختبار API مع خطة Bamboo

قبل الشرح خطوة بخطوة، من المفيد فهم مكان هذا في نموذج Bamboo. ينظم Bamboo العمل في خطط (plans)، وتحتوي كل خطة على مرحلة واحدة أو أكثر (stages) يتم تشغيلها بالترتيب. وتحتوي كل مرحلة على وظائف (jobs)، وكل وظيفة هي تسلسل من المهام (tasks). المهام هي الأوامر الفعلية: سحب الكود (checkout)، تجميع (compile)، تشغيل نص برمجي (run a script).

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

Plan: payments-service (الخطة: خدمة المدفوعات)
├── Stage: Build (المرحلة: بناء)
│   └── Job: Compile & Unit Test (الوظيفة: تجميع واختبار الوحدات)
│       ├── Task: Source Code Checkout (المهمة: سحب الكود المصدري)
│       └── Task: Maven, clean package (المهمة: Maven، حزمة نظيفة)
├── Stage: Deploy to Staging (المرحلة: نشر إلى بيئة التطوير)
│   └── Job: Deploy (الوظيفة: نشر)
│       └── Task: Deploy artifact to staging (المهمة: نشر الأثر إلى بيئة التطوير)
└── Stage: API Tests          <- هذا ما تضيفه أنت
    └── Job: Run API Suite (الوظيفة: تشغيل مجموعة API)
        ├── Task: Source Code Checkout (المهمة: سحب الكود المصدري)
        ├── Task: Script, install & run Apidog CLI (المهمة: نص برمجي، تثبيت وتشغيل Apidog CLI)
        └── Task: Final, publish test report (المهمة: نهائي، نشر تقرير الاختبار)

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

الأداة التي تقوم بالعمل الفعلي في مهمة النص البرمجي هذه هي Apidog CLI، وهي أداة سطر أوامر تقوم بتنفيذ سيناريوهات الاختبار التي تصممها بصريًا في Apidog. تقوم ببناء الاختبار مرة واحدة، في واجهة رسومية، بدون كود، ويتم تشغيل نفس الاختبار دون تغيير في محطتك الطرفية وفي Bamboo. هذا هو نفس النمط الذي تستخدمه الفرق لأتمتة اختبارات API عبر أي نظام CI/CD؛ Bamboo هو هدف واحد من بين العديد.

الخطوة 1: بناء اختبارات API الخاصة بك في Apidog

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

افتح Apidog وأنشئ سيناريو اختبار. السيناريو هو تسلسل مرتب لطلبات API، يتم تشغيله من الأعلى إلى الأسفل، حيث يمكن لكل خطوة إعادة استخدام البيانات من الخطوات التي سبقتها. قد يكون سيناريو واقعي لخدمة المدفوعات كالتالي:

1. POST /auth/login ببيانات اعتماد صالحة، ثم استخرج رمز التوثيق (bearer token) من الاستجابة.
2. POST /orders باستخدام هذا الرمز، لإنشاء طلب جديد، ثم احفظ orderId العائد.
3. GET /orders/{orderId} وتأكيد ظهور الطلب بالحالة الصحيحة.
4. DELETE /orders/{orderId} للتنظيف.

لكل طلب، أضف تأكيدات. هذا هو الجزء الذي يحول الطلب إلى اختبار. يتيح لك Apidog التأكيد بصريًا، بدون الحاجة إلى برمجة:

• رمز الحالة يساوي 200 (أو 201، أيا كان ما ينص عليه العقد).
• يوجد حقل JSON ويطابق: $.data.status يساوي "pending".
• تتحقق الاستجابة مقابل مخطط OpenAPI لنقطة النهاية، لذا فإن أي نوع حقل غير متوقع أو خاصية مطلوبة مفقودة ستفشل الخطوة.
• يبقى وقت الاستجابة تحت حد معين، على سبيل المثال 800 مللي ثانية، لذلك تظهر أي انحدارات بطيئة أيضًا.

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

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

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

الخطوة 2: إنشاء رمز وصول Apidog والحصول على المعرفات

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

داخل سيناريو الاختبار الخاص بك، افتح علامة التبويب CI/CD. انقر فوق "إضافة رمز وصول" (Add access token)، ثم "إنشاء رمز" (Generate token). انسخ القيمة في مكان آمن للحظة؛ ستقوم بتخزينها كمتغير Bamboo قريبًا، لا تلصقها في نص برمجي. الرمز هو ما يسمح لعامل البناء بسحب وتشغيل اختبارات مشروعك الخاص.

بينما أنت في علامة التبويب CI/CD هذه، يقوم Apidog بإنشاء أمر التشغيل الكامل لك. حدد "سطر الأوامر" (Command line) كموفر وسيطبع شيئًا يمكنك نسخه مباشرة، مع معرف سيناريو الاختبار ومعرف المشروع الخاصين بك مملوءين بالفعل. هذا الأمر المنسوخ هو أساس مهمة Bamboo الخاصة بك. الأجزاء التي تهمك:

• رمز الوصول: المصادقة، يتم تمريره كـ --access-token.
• معرف سيناريو الاختبار: المعرف الرقمي بعد -t، يحدد السيناريو المراد تشغيله.
• معرف البيئة: المعرف الرقمي بعد -e، يخبر CLI بالتشغيل مقابل بيئة التطوير.

احتفظ بهذا الأمر الذي تم إنشاؤه في متناول اليد. ستكيفه الخطوات التالية لـ Bamboo.

الخطوة 3: تخزين الرمز المميز كمتغير في خطة Bamboo

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

في Bamboo، انتقل إلى خطتك، افتح "تكوين الخطة" (Plan Configuration)، وابحث عن علامة التبويب "المتغيرات" (Variables). أضف متغيرًا جديدًا. سمّه شيئًا واضحًا مثل APIDOG_ACCESS_TOKEN والصق الرمز المميز كقيمة. يقوم Bamboo بإخفاء المتغيرات التي تحتوي أسماؤها على password، أو secret، أو token، لذا سمّه وفقًا لذلك وستُخفى القيمة في السجلات وواجهة المستخدم.

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

ينطبق هذا النظافة نفسها على أي سر آخر تحتاجه اختباراتك؛ كلمات مرور قواعد البيانات، مفاتيح API لجهات خارجية، أسرار التوقيع. قم بتعريفها كمتغيرات Bamboo مخفية واقرأها من خلال بادئة البيئة bamboo_.

الخطوة 4: إضافة مرحلة اختبار API ومهمة نص برمجي

الآن قم بتوصيلها بالخطة. في "تكوين الخطة" (Plan Configuration)، أضف مرحلة جديدة وسمها "اختبارات API" (API Tests). أضف وظيفة إليها، ثم أضف مهام إلى الوظيفة بهذا الترتيب.

المهمة 1، "سحب الكود المصدري" (Source Code Checkout). على الرغم من أن الاختبارات موجودة في سحابة Apidog، فإن سحب مستودعك يمنح العامل دليل عمل نظيف ويسمح لك بتسليم أي ملفات بيانات محلية (بيانات تكرارية CSV، على سبيل المثال) جنبًا إلى جنب مع الكود الخاص بك.

المهمة 2، "نص برمجي" (Script). هذا هو جوهر الأمر. اختر مهمة "نص برمجي"، عيّن المفسر إلى "شِل" (Shell) (أو /bin/sh)، واستخدم نصًا برمجيًا مضمنًا. يقوم النص البرمجي بتثبيت Apidog CLI على العامل وتشغيل السيناريو الخاص بك.

Apidog CLI هو حزمة npm، لذا يحتاج العامل إلى Node.js v16 أو أحدث. إذا كان عملاؤك يمتلكون Node بالفعل، يمكنك تخطي سطر التثبيت؛ وإلا، قم بتوفيره من خلال إمكانيات Bamboo أو عامل قائم على Docker. إليك نص برمجي كامل:

#!/bin/sh
set -e

# Install the Apidog CLI globally on the agent (تثبيت Apidog CLI عالميًا على العميل)
npm install -g apidog-cli

# Run the test scenario against staging, output an HTML + CLI report (تشغيل سيناريو الاختبار مقابل بيئة التطوير، وإخراج تقرير HTML + CLI)
apidog run \
  --access-token "$bamboo_APIDOG_ACCESS_TOKEN" \
  -t 637132 \
  -e 358171 \
  -r cli,html \
  --out-dir ./apidog-reports

استبدل 637132 بمعرف سيناريو الاختبار الحقيقي الخاص بك و 358171 بمعرف بيئة التطوير الخاصة بك، القيم من الأمر الذي أنشأه Apidog في الخطوة 2. بعض الملاحظات حول ما يفعله كل علم:

• --access-token يقرأ متغير Bamboo المخفي، لذلك لا يظهر السر أبدًا في النص البرمجي.
• -t (اختصار لـ --test-scenario) يختار السيناريو للتشغيل. لتشغيل مجموعة كاملة بدلاً من ذلك، استخدم --test-suite <id>؛ لتشغيل مجلد كامل من السيناريوهات، استخدم -f <folderId>.
• -e (--environment) يختار بيئة التطوير التي حددتها في Apidog، لذلك تذهب الطلبات إلى المضيف الصحيح بالمتغيرات الصحيحة.
• -r cli,html (--reporters) ينتج تقريرًا للوحة التحكم سترى في سجل بناء Bamboo وتقرير HTML يمكنك نشره كأثر. تدعم CLI أيضًا تنسيقات json و junit هنا.
• --out-dir يتحكم في مكان هبوط التقارير. الافتراضي هو ./apidog-reports؛ تعيينه صراحة يجعل مسار الأثر قابلاً للتنبؤ به.

يعد set -e في الأعلى مهمًا. فهو يجعل الـ shell يخرج عند أول أمر فاشل. يقوم Apidog CLI بالفعل بإرجاع رمز خروج غير صفري عندما يفشل أي تأكيد، وهذا الرمز غير الصفري هو ما يخبر Bamboo بفشل البناء. معًا يضمنان أن العقد المعطل يحول البناء إلى اللون الأحمر بدلاً من أن يدفن في السجلات.

إذا قمت بتوصيل اختبارات API بـ GitHub Actions من قبل، فسيبدو هذا مألوفًا؛ فالمشغل والأعلام متطابقان، فقط تختلف واجهة المستخدم بين YAML و Bamboo.

الخطوة 5: نشر تقرير الاختبار كأثر من Bamboo

البناء الأحمر يخبرك أن شيئًا ما قد تعطل. يخبرك تقرير HTML ماذا تعطل. قم بتهيئته بحيث يحتفظ كل بناء بالتقرير.

في نفس الوظيفة، انتقل إلى علامة التبويب "الآثار" (Artifacts) وحدد أثرًا مشتركًا جديدًا:

• الاسم: Apidog Test Report
• الموقع: apidog-reports
• نمط النسخ: **/*

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

للعرض الأكثر ثراءً داخل Bamboo، يكون مراسل junit مفيدًا أيضًا. أضف junit إلى قائمة -r، ثم أضف مهمة محلل JUnit موجهة إلى ملف JUnit XML. يقوم Bamboo بعد ذلك بعرض عدد الاختبارات، وتفاصيل النجاح/الفشل، واتجاهات الفشل محليًا في ملخص البناء، بنفس الطريقة التي يعرض بها نتائج اختبارات الوحدات الخاصة بك.

الخطوة 6: تشغيله وقراءة النتيجة

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

نتيجتان:

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

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

ملخص وحدة تحكم واقعي يبدو كالتالي:

┌──────────────┬──────────┬──────────┐
│              │ executed (تم التنفيذ) │   failed (فشل) │
├──────────────┼──────────┼──────────┤
│   iterations (تكرارات) │        1 │        0 │
├──────────────┼──────────┼──────────┤
│     requests (طلبات) │        4 │        0 │
├──────────────┼──────────┼──────────┤
│   assertions (تأكيدات) │       11 │        1 │
└──────────────┴──────────┴──────────┘

  1 assertion failed: (فشل تأكيد واحد:)
    GET /orders/{orderId}
      expected $.data.status to equal "pending" but got "failed" (كان المتوقع أن يكون $.data.status يساوي "pending" ولكنه كان "failed")

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

جعل المجموعة موثوقة في CI

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

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

استخدم عمليات تشغيل تعتمد على البيانات للتغطية بدون تكرار. إذا كنت بحاجة إلى اختبار نفس نقطة النهاية بعشرين مدخلًا مختلفًا، فلا تبنِ عشرين سيناريو. استخدم سيناريو واحدًا مع --iteration-data path/to/data.csv (أو -d)، وتقوم واجهة سطر الأوامر (CLI) بتشغيله مرة واحدة لكل صف. قم بتسليم ملف CSV إلى المستودع الخاص بك بحيث يتم سحبه مع الكود. هذا هو نفس نمط الاختبار القائم على البيانات الذي ستستخدمه محليًا، ولكن يتم تشغيله من ملف في CI.

تثبيت إصدار CLI. يقوم npm install -g apidog-cli بسحب الأحدث. للبناءات القابلة للاستنساخ، قم بتثبيت إصدار معروف، npm install -g apidog-cli@<version>، حتى لا يغير تحديث CLI السلوك بصمت بين بناءين لنفس الالتزام.

عيّن مهلات معقولة. أضف --timeout-request 10000 للفشل بسرعة في نقطة نهاية معلقة بدلاً من ترك البناء معلقًا حتى تقتله المهلة الخاصة بـ Bamboo. "طلب انتهت مهلته" واضح أفضل من بناء متوقف غامض.

تحكم في عمليات النشر في مرحلة API. نظرًا لأن مرحلة اختبارات API (API Tests) تعمل قبل أي مرحلة نشر للإنتاج، وتوقف المرحلة الفاشلة الخطة، فإن العقد المعطل لا يمكنه الوصول إلى الإنتاج. هذا الترتيب هو بوابة الإصدار الخاصة بك. إنه النسخة العملية من بناء خط أنابيب CI/CD حقيقي بدلاً من بناء يقتصر على التجميع.

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

الخلاصة

يحميك Bamboo بالفعل من الكود الذي لا يجمع واختبارات الوحدات التي لا تمر. إضافة مرحلة اختبار API تمد هذا الحماية إلى العقود التي تكشفها خدماتك بالفعل عبر الشبكة، وهي الطبقة التي تحدث فيها معظم حوادث "لكنه عمل محليًا" بالفعل.

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

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