Ring Promoter — بوابات ضمان الجودة قبل الإنتاج

شاهد: بوابات ضمان الجودة قبل الإنتاج

فيديو: youtu.be/Vs2Em0HPvoY · منتج: ringpromoter.com

Ring Promoter هو مستوى التحكم في الترويج لـ Workstation للحلقات المطلوبة int → test → acc → prod. تركز هذه المقالة على ضمان الجودة وبوابات الجودة في هذا الخط: مكان جلوسهم، وكيفية تفاعل الترويج التلقائي مع البوابات البشرية (خاصة قبل الإنتاج)، والتحقق من الصحة والإصدار كبوابات من الدرجة الأولى، وسلوك التراجع، والآثار المترتبة على فرق منصة الذكاء الاصطناعي. منتج: ringpromoter.com · مصدر: github.com/bwalia/ring-promoter. مدونة رفيقة: موجز الأعمال · ملخص: مقالة CI/CD حديثة · صفحة المنتج: /ring-promoter.

1. عملية الترويج (الخلاصة)

تعلن التطبيقات عن أهداف النشر لكل حلقة (مساحة الاسم، النشر، مستودع الصور، عنوان URL الصحي، الموزع). تتم مشاركة الحلقات نفسها وترتيبها. يتصل المشغلون أو CI أو الوكلاء بما يلي:

• بذرة - قم بتشغيل الإصدار int (أو حلقة دخول تم تكوينها).
• يرقي - نقل الإصدار من from_ring إلى التالي حلقة فقط.
• التراجع - استعادة الإصدار السابق على الحلقة (أيضًا تلقائيًا في حالة فشل حالة ما بعد النشر).

التزامن: يتم إجراء تسلسل لعمليات نفس التطبيق (قفل استشاري جلسة Postgres عبر النسخ المتماثلة). يتم فصل سياق العملية عن طلب HTTP ويحده operation_timeout، لذلك لا يمكن لقطع اتصال العميل إلغاء الترويج أثناء الرحلة أو التراجع عنه.

Operators / CI / Agents
    → Ring Promoter (UI + REST API)
        → seed / promote / rollback
        → Deployer (kubectl | GitHub Actions | k8sjob)
        → Health (HTTP + optional version verify)  ← quality gate
        → optional auto_promote to next ring       ← policy gate
        → Store (Postgres history + locks)
Rings: int → test → acc → prod

2. أين تقع بوابات ضمان الجودة

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

3. الترويج التلقائي للأعلام لكل حلقة

الترويج التلقائي هو اختياري ولكل حلقة. عندما يصل الإصدار إلى حلقة تم تمكين الترويج التلقائي لها، يستمر Ring Promoter إلى الحلقة التالية داخل نفس العملية المقفلة. مثال لرسم السياسة:

# Conceptual ring policy (illustrative)
rings:
  - name: int
    auto_promote: true      # healthy int → continue to test
  - name: test
    auto_promote: true      # healthy test → continue to acc
  - name: acc
    auto_promote: false     # HUMAN GATE — stop before prod
  - name: prod
    auto_promote: false     # terminal ring

لا تزال تعيينات الحلقة على مستوى التطبيق تحمل تفاصيل النشر والصحة:

# Per-app ring mapping (illustrative)
apps:
  web-frontend:
    rings:
      acc:
        namespace: acc-apps
        deployment: web-frontend
        health_url: https://acc.example/healthz
        health_version_field: version
      prod:
        namespace: prod-apps
        deployment: web-frontend
        health_url: https://www.example/healthz
        health_version_field: version

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

4. التحقق من الصحة والإصدار كبوابات الجودة

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

صحة الإصدار الذي تم التحقق منه يحول عنوان URL العادي إلى بوابة جودة:

• health_version_field — حقل JSON في الجسم الصحي (على سبيل المثال version أو build.version).
• health_version_header - رأس مثل X-App-Version.

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

على المرجع مثبت حلقات (ref: release)، قد لا يكون الإصدار المتوقع معروفًا مقدمًا - بعد النشر السليم يمكن لطائرة التحكم سِجِلّ الإصدار الذي تُبلغ عنه نقطة النهاية بدلاً من مقارنته بعلامة معروفة مسبقًا.

5. ACC → همز البوابة البشرية

حفظ auto_promote: false على acc يعني ناجح test → acc (أو سلسلة تلقائية من حلقات سابقة) يتوقف عند القبول. يتطلب الإنتاج ترويجًا صريحًا - نقرة على واجهة المستخدم، أو استدعاء API معتمد، أو أتمتة مدعومة بتذكرة التغيير والتي لا تزال تستدعي الترويج عمدًا.

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

6. التراجع كجزء من قصة البوابة

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

البوابات بدون التراجع هي مسرح. يتعامل Ring Promoter مع البوابات الفاشلة على أنها قابلة للتنفيذ: عكس القفزة السيئة، والحفاظ على مسار التدقيق، وترك الحلقات السابقة سليمة.

7. اسكتشات API (CI / الوكلاء)

# Seed int, then promote (auto-promote may chain further)
curl -s -H "Authorization: Bearer $TOKEN" -X POST \
  -d '{"ring":"int","version":"1.4.2"}' \
  $BASE/api/apps/web-frontend/seed

curl -s -H "Authorization: Bearer $TOKEN" -X POST \
  -d '{"from_ring":"int"}' \
  $BASE/api/apps/web-frontend/promote
# non-2xx = failed promotion (target auto-rolled back)

# Explicit human-gated hop into prod (after QA on acc)
curl -s -H "Authorization: Bearer $TOKEN" -X POST \
  -d '{"from_ring":"acc"}' \
  $BASE/api/apps/web-frontend/promote

بناء واختبار CI؛ ينقل Ring Promoter ما أنتجته CI. الترويج غير 2xx يعني فشل البوابة - curl --fail يكفي لتكامل خطوط الأنابيب. يجب أن يعالج الوكلاء وروبوتات الإصدار acc → prod كإجراء مميز مع خطوة موافقة صريحة في سير العمل الخاص بهم.

8. الآثار المترتبة على فرق منصة الذكاء الاصطناعي

تعمل عقارات الذكاء الاصطناعي على تعزيز خدمات الاستدلال وأوقات تشغيل الوكيل وبوابات MCP وRAG APIs والخدمات الكلاسيكية على ساعات وأدوات نشر مختلفة (kubectl vs GitHub Actions vs k8sjob). الحلقات المشتركة تعطي لغة ترويجية واحدة؛ البوابات تحافظ على تلك اللغة صادقة:

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

موقف Workstation: تعامل مع شحن الذكاء الاصطناعي مثل خدمات الإنتاج - القابلية للملاحظة والانضباط الترويجي أولاً (انظر أيضًا اختناقات LLM / OTEL)، ثم السرعة.

9. الإيجابيات والسلبيات والسياسة الموصى بها

الافتراضي الموصى به: تفعيل_الترويج_التلقائي int و test; بوابة الإنسان على acc; صحة الإصدار التي تم التحقق منها في كل تطبيق يواجه العملاء؛ لا تخطي الحلقات أبدًا؛ الاعتماد على التراجع التلقائي عند فشل البوابات.

10. البدء

1. يشاهد youtu.be/Vs2Em0HPvoY.
2. يزور ringpromoter.com واستنساخ github.com/bwalia/ring-promoter.
3. اقرأ مدونة الأعمال وWorkstation صفحة المنتج.
4. تكوين لكل حلقة auto_promote وحقول الإصدار الصحي؛ إبقاء همز الإنسان بوابات.
5. تحدث إلى Workstation عبر اتصال حول CI/CD لمنصات الذكاء الاصطناعي.

نشرت من قبل Workstation. المستندات الأولية: الملف التمهيدي وملاحظات التصميم في مستودع Ring Promoter.

موقع المنتج: https://www.ringpromoter.com/