صفحة الإصدارات

اضبط release على حزم SDK لديك وسجّل الإصدارات وعمليات النشر من خط الأنابيب (راجع «الإصدارات وخرائط المصدر»). تعرض صفحة الإصدارات بعدها أداء كل نسخة، وأي الالتزامات تسببت على الأرجح في مشكلة، ومن يملك الكود.

1صحة الإصدار

لكل إصدار: التبنّي (حصته من جلسات المشروع)، والجلسات الخالية من الأعطال، والمستخدمون بلا أعطال، والأحداث، والمشكلات الجديدة، والانتكاسات، وآخر نشر. تُقرّب المعدلات للأسفل كي لا يظهر عطل واحد أبدًا كـ 100%. تأتي الجلسات من حزم Sentry SDK، أو من POST /api/v1/sessions، أو من SDK المتصفح مع autoSessionTracking: true وrelease. يُحتفظ بالجلسات لمدة 90 يومًا.

2الالتزامات المشتبه بها

تعرض صفحة المشكلة حتى خمسة التزامات من أول إصدار ظهرت فيه المشكلة تطابق ملفاتها المتغيرة إطار stack داخل التطبيق (يجب أن يتفق آخر جزأين من المسار، لذا ارفع خرائط المصدر للحزم المصغّرة). تأتي الالتزامات من واجهة مقارنة GitHub عند حفظ رمز، وإلا مما أرسله CLI.

3رمز GitHub

احفظ رمزًا لكل مشروع في صفحة مالكي الكود. يُشفّر، ولا يُعرض منه سوى تلميح من 4+4 أحرف، ولا يُستخدم إلا مع api.github.com.

4قواعد مالكي الكود

تربط القاعدة نمط glob لمسار ملف أو نمط URL ببريد إلكتروني أو تسمية فريق مثل #payments. أنماط المسارات: src/checkout/** و*.py وmodels/*.py؛ يبقى * داخل مجلد واحد، ويعبر ** المجلدات، ويطابق النمط عند أي حد مجلد. أنماط URL مثل */checkout* لا تميّز حالة الأحرف. بحد أقصى 4 أحرف بدل و256 حرفًا لكل نمط، و200 قاعدة لكل مشروع. يظهر المالكون المطابقون في صفحة المشكلة، ويتلقى المالكون الذين هم عناوين بريد نسخًا من التنبيهات.

ini
src/checkout/**      ana@example.com
models/*.py          #odoo-team
*/checkout*          payments@example.com

من المفيد معرفته

  • تحسب الانتكاسات في صفحة الإصدارات المشكلات التي حُلّت ثم عادت في ذلك الإصدار.
  • يحتاج «مستخدمون بلا أعطال» إلى جلسات بمعرّف مستخدم؛ وأعداد الجلسات المجمّعة لا تحمله.

هل واجهتك مشكلة؟ راسل support@blipit.io. المفاتيح وDSN الدقيق لكل مشروع موجودة تحت مفاتيح API في app.blipit.io.