Staged Rollout — ما هو وكيف يعمل الإصدار التدريجي

ما هو Staged Rollout؟

Staged Rollout هي ميزة في Google Play Console للتوزيع التدريجي لتحديثات التطبيقات. يحدد المطور نسبة المستخدمين الذين سيحصلون على الإصدار الجديد ويزيد التغطية تدريجيًا مع مراقبة الاستقرار ومقاييس الجودة. يتم الإصدار الكامل لجميع المستخدمين فقط بعد تأكيد عدم وجود مشكلات حرجة.

تعمل الآلية على مستوى متجر التطبيقات: Google Play يوزع التحديث تلقائيًا بين النسبة المحددة من الأجهزة. لا يرى المستخدمون فرقًا — بالنسبة لهم هو تحديث عادي من المتجر. داخل الشريحة المحددة، يتم اختيار المستخدمين عشوائيًا، مما يضمن عينة تمثيلية.

تاريخ ظهور الميزة

قدمت Google Staged Rollout في 2015 كجزء من Google Play Developer Console. قبل هذه الميزة، كان المطورون ينشرون التحديثات لجميع المستخدمين دفعة واحدة، مما أدى إلى أعطال جماعية عند حدوث أخطاء. وفقًا لبيانات Google I/O 2023، أدى تطبيق الإصدارات التدريجية إلى تقليل عدد الحوادث الحرجة في تطبيقات Android بنسبة 60%.

متى يُستخدم Staged Rollout

يُستخدم الإصدار التدريجي عند نشر تغييرات كبيرة: تصميم جديد، تغيير البنية، تحديث SDK، ترحيل قاعدة البيانات أو الترقية إلى إصدار API جديد. Staged Rollout يُوصى به أيضًا لاختبار A/B لمقاييس الإنتاج قبل النشر الكامل.

كيف يعمل Staged Rollout

بعد تحميل APK أو App Bundle في Google Play Console، يختار المطور Staged Rollout بدلاً من الإصدار الكامل. يطلب النظام تحديد نسبة المستخدمين من 5% إلى 100% بزيادات 5%. يقوم Google Play تلقائيًا بتوزيع التحديث بين النسبة المحددة من المستخدمين المختارين عشوائيًا.

خوارزمية التوزيع

يستخدم Google Play خوارزمية حتمية تعتمد على معرف الجهاز ورقم إصدار الكود. يضمن هذا أن المستخدم الذي حصل على التحديث عند 10% لن يفقده عند زيادة النسبة إلى 20%. التوزيع مستقر: المستخدم إما لديه الإصدار بالفعل أو سيحصل عليه عند الزيادة التالية في التغطية.

// build.gradle — الإصدارات لـ Staged Rollout
android {
    defaultConfig {
        versionCode 42
        versionName "2.4.0-staged"
    }
}

// بعد تأكيد الاستقرار — الإصدار الكامل
// versionCode يبقى كما هو، versionName → "2.4.0"

مراقبة المقاييس أثناء العملية

بعد بدء Staged Rollout، من الضروري تتبع المؤشرات الرئيسية: عدد ANR، معدل الأعطال، التقييم ومراجعات المستخدمين. توفر Google Play Console لوحة مقاييس في الوقت الفعلي. عند تجاوز الحدود، يُوصى بإيقاف الإصدار فورًا وإجراء التراجع.

الإعداد في Google Play Console

يتم إعداد Staged Rollout في ثلاث خطوات ولا يتطلب تغييرات في كود التطبيق. يكفي تحميل البنية إلى Google Play Console واختيار خيار الإصدار التدريجي. فيما يلي دليل خطوة بخطوة مع أقسام محددة من الواجهة.

• انتقل إلى Google Play Console → Release → Production
• انقر Create new release وحمّل App Bundle
• اختر Staged rollout وحدد نسبة المستخدمين
• أكد الإصدار وابدأ التوزيع التدريجي
• راقب المقاييس في لوحة Dashboard

اختيار نسبة التغطية

للمرحلة الأولى، يُوصى باختيار 5–10% من المستخدمين. هذا هو الحد الأدنى التمثيلي لتحديد الأخطاء الحرجة. في حالة عدم وجود مشكلات، تزداد النسبة إلى 25% و50% و100% بفاصل 24–48 ساعة. الزيادة السريعة في التغطية مبررة فقط للتغييرات الطفيفة.

قيود Staged Rollout

الميزة متاحة فقط لإصدارات الإنتاج في Google Play. تُستخدم آليات منفصلة للاختبار المفتوح والمسارات المغلقة. لا يمكن تطبيق Staged Rollout على دول أو مناطق فردية — تُحسب النسبة من إجمالي جمهور التطبيق. للاستهداف الجغرافي، تُستخدم إصدارات خاصة بكل دولة. كما لا يمكن تعيين نسب مختلفة لقنوات توزيع مختلفة — يتم اختيار جميع المستخدمين عشوائيًا بغض النظر عن مصدر التثبيت.

مزايا الإصدار التدريجي

Staged Rollout يقلل مخاطر النشر من خلال السماح باكتشاف المشكلات على عينة صغيرة من المستخدمين. على عكس الاختبار على المسارات الداخلية، يكشف حركة الإنتاج سيناريوهات الاستخدام الحقيقية التي لا يمكن إعادة إنتاجها في بيئة QA. وفقًا لتحليل Google Play Console (2024)، يتم اكتشاف 70% من الأخطاء الحرجة تحديدًا خلال مرحلة الإصدار التدريجي.

التأثير على تجربة المستخدم

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

التكامل مع CI/CD

Staged Rollout مدعوم في Google Play Developer API، مما يسمح بأتمتة الإصدارات التدريجية عبر خطوط أنابيب CI/CD. توفر أدوات مثل Gradle Play Publisher وFastlane أوامر جاهزة لتكوين نسبة التغطية ومراقبة حالة الإصدار عبر نصوص البناء.

معايير الانتقال بين المراحل

قبل زيادة نسبة التغطية، تحقق من ثلاثة معايير رئيسية: معدل الأعطال أقل من 0.5%، عدد ANR لا يتجاوز خط الأساس للإنتاج، تقييم التطبيق لم ينخفض بأكثر من 0.2 نجمة. إذا تم انتهاك معيار واحد على الأقل — أوقف Staged Rollout، حلل الأسباب وانشر بنية مصححة بدءًا من الحد الأدنى للنسبة.

التراجع وإلغاء التغييرات

التراجع هو العودة إلى الإصدار المستقر السابق للتطبيق في Google Play. إذا تم اكتشاف خطأ حرج أثناء Staged Rollout، يمكن للمطور إيقاف التوزيع وإعادة جميع المستخدمين إلى الإصدار السابق. تتم العملية في Google Play Console دون نشر بنية جديدة.

كيفية إجراء التراجع

للتراجع، انتقل إلى قسم Release → Production واختر خيار Rollback to previous release. يقوم Google Play تلقائيًا بإيقاف توزيع الإصدار الحالي وإعادة المستخدمين إلى الإصدار المستقر السابق. جميع المستخدمين الجدد الذين دخلوا الشريحة يتم تحويلهم أيضًا إلى الإصدار القديم عند التحديث التالي من المتجر.

عندما لا يكون التراجع ممكنًا

إذا تم حذف الإصدار السابق من Google Play أو انتهت صلاحيته، التراجع غير متاح. يُوصى دائمًا بالاحتفاظ بإصدار مستقر واحد على الأقل في قسم Production. يمكن استعادة الإصدار منتهي الصلاحية مؤقتًا عبر دعم Google Play Console.

التراجع التلقائي حسب المقاييس

يسمح Google Play Console بتكوين تراجع تلقائي عند تجاوز حدود معدل الأعطال أو ANR. في قسم Release → Production، حدد المشغلات: إذا تجاوز معدل الأعطال 1%، يقوم Google Play تلقائيًا بإيقاف Staged Rollout والعودة إلى الإصدار السابق. هذا يقلل وقت الاستجابة للحوادث إلى دقائق دون تدخل المطور. يتطلب تكوين المشغلات حسابًا بدور محرر أو مسؤول.

Staged Rollout مقابل الإصدار الكامل

يعتمد الاختيار بين Staged Rollout والإصدار الكامل على نوع التغييرات ومستوى المخاطرة. الإصدار الكامل مبرر للإصلاحات الطفيفة وتحديثات التبعيات دون تغيير المنطق. الإصدار التدريجي إلزامي للتحديثات الرئيسية وتغييرات البنية والتغييرات التي تؤثر على الأمان أو بيانات المستخدمين.

توصيات الاختيار

للتحديثات التي تؤثر على أكثر من 20% من الكود، Staged Rollout إلزامي. تتطلب تغييرات UI وUX أيضًا نشرًا تدريجيًا لتقييم رد فعل المستخدمين. الإصدار الكامل مقبول لإصلاحات النصوص وتحديثات SDK دون تغيير API وتصحيحات الأمان منخفضة مخاطر الانحدار. عند الشك، اختر دائمًا الإصدار التدريجي — تكلفة التراجع أقل بكثير من الضرر المحتمل من فشل جماعي لإصدار الإنتاج.