ماذا يحدث بعد الضغط على "رفع" في Google Play و App Store

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

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

الرفع أكثر من مجرد نقل ملف

عند رفع حزمة Android App Bundle (AAB) أو ملف iOS IPA، يتوقع المتجر أكثر من مجرد الملف الثنائي. تحتاج أيضًا إلى تقديم:

  • عنوان التطبيق ووصفه للإصدار الجديد
  • ما الذي تغير في هذا الإصدار (سجل التغيير)
  • لقطات شاشة لأحجام أجهزة متعددة
  • تحديثات فئة التطبيق وتصنيف المحتوى
  • أي البلدان أو المناطق ستحصل على التحديث

كلا من Google Play Console و App Store Connect يوفران واجهات برمجة تطبيقات (APIs) تسمح لخط أنابيبك بالتعامل مع كل هذا برمجيًا. يمكن لنظام CI/CD الخاص بك دفع القطعة الأثرية، وملء البيانات الوصفية، وإرفاق لقطات الشاشة الصحيحة، وتعيين مسار الإصدار. بالنسبة لنظام Android، يمكنك الرفع إلى الاختبار الداخلي، أو الاختبار المغلق، أو الاختبار المفتوح قبل التفكير في الإنتاج. بالنسبة لنظام iOS، ترفع إلى TestFlight أولاً.

يوضح مخطط التسلسل التالي التدفق النموذجي من خط الأنابيب إلى الإصدار:

sequenceDiagram participant CI as CI/CD Pipeline participant Store as Store API participant Review as Review Queue participant Track as Release Track CI->>Store: Upload binary + metadata Store->>Review: Submit for review Review-->>Store: Approval or rejection alt Rejected Store-->>CI: Rejection notice CI->>Store: Fix and re-upload else Approved Store->>Track: Set release track (internal/closed/open/production) Track->>Track: Staged rollout or full release end

الرؤية الرئيسية هنا هي أن خطوة الرفع لا ينبغي أن تكون نهاية خط الأنابيب الخاص بك. بل يجب أن تكون بداية عملية إصدار محكومة.

لماذا لا يجب الرفع مباشرة إلى الإنتاج

من المغري بناء خط أنابيب ينتقل مباشرة من "اجتياز الاختبارات" إلى "النشر في المتجر". لكن متاجر الجوال تضيف بوابة غير موجودة في نشر الويب أو الخلفية: المراجعة البشرية.

تراجع Apple كل تطبيق وتحديث مقابل إرشادات مراجعة App Store. كما تراجع Google الطلبات، على الرغم من أن العملية بشكل عام أسرع وأقل صرامة. إذا رفع خط أنابيبك مباشرة إلى الإنتاج ووجدت المراجعة مشكلة، فسيتعين عليك إصلاحها وإعادة الرفع والانتظار مرة أخرى. قد يؤخر ذلك إصدارك لأيام.

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

البيانات الوصفية ولقطات الشاشة يجب أن تتطابق مع البناء

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

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

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

خطط لوقت المراجعة في جدول الإصدار الخاص بك

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

لا تفترض أن المراجعة الأولى ستنجح. حتى الفرق ذات الخبرة تتعرض للرفض لأشياء مثل:

  • طلب أذونات دون شرح السبب
  • استخدام واجهات برمجة تطبيقات خاصة
  • بيانات وصفية غير كاملة أو غير صحيحة
  • عناصر واجهة مستخدم لا تتطابق مع لقطات الشاشة
  • انتهاكات سياسات المتجر المحددة (مثل قواعد Apple حول المشتريات داخل التطبيق)

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

ماذا يحدث بعد اجتياز المراجعة

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

على Android، يمكنك استخدام الطرح التدريجي لإصدار التحديث لنسبة مئوية من المستخدمين، مثل 10٪ أو 25٪. على iOS، يمكنك استخدام الإصدار المرحلي، الذي يطرح التحديث تدريجيًا على مدار عدة أيام. يتيح لك هذا مراقبة معدلات الأعطال وملاحظات المستخدمين والمقاييس الرئيسية قبل التوسع للجميع.

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

قائمة مراجعة عملية لرفع المتجر

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

الخلاصة

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