يتيح لك الويب إصلاح الخطأ في دقائق، أما الهاتف فلا: قد تبقى نسخة معطوبة أمام المستخدمين أيامًا بينما يتحرّك طابور المراجعة. وهذا الفارق وحده ينبغي أن يشكّل طريقة إطلاقك.
افصل الإطلاق عن الإصدار
انشر الكود معطّلًا خلف مفتاح تشغيل، ثم فعّل الميزة من الخادم بعد أن تصل إلى عدد كافٍ من الأجهزة. عندها يصبح «التراجع» تغييرًا في الإعدادات لا تقديمًا طارئًا للمتجر، ويمكن لأي شخص مستيقظ إيقاف ميزة تسيء التصرّف عند الثانية فجرًا.
أطلق على مراحل
يدعم المتجران الإطلاق التدريجي، فاستخدمه. نسبة واحد بالمئة ليوم واحد تكشف الانهيار الذي لا يحدث إلا على جهاز أندرويد عمره ثلاث سنوات بلغة لم تختبرها.
راقب الرقم الصحيح
نسبة الجلسات الخالية من الانهيار هي المؤشر البارز، لكنها تخفي الأعطال البطيئة. تابع معدّل إتمام مسارك الحرج الواحد — التسجيل أو الدفع أو الحجز — لكل إصدار. فإصدار لا ينهار لكنه يخفض إتمام الدفع ثماني نقاط أسوأ من إصدار ينهار.
اجعل بناء العميل قابلًا لإعادة الإنتاج
وجود مفاتيح التوقيع في حاسوب شخص واحد هو أشيع طريقة يصبح بها المشروع غير قابل للصيانة. ضع المفاتيح في خزانة أسرار العميل نفسه، واجعل التكامل المستمر قادرًا على إنتاج نسخة إصدار من نسخة نظيفة، ووثّق إجراءً اتّبعه شخص آخر مرة واحدة على الأقل.
ابنِ مفتاح التحديث الإلزامي قبل أن تحتاجه
عاجلًا أو آجلًا سيجب إخراج نسخة من الخدمة: إصلاح أمني، أو تغيير كاسر في الواجهة البرمجية، أو خلل يُفسد البيانات. وإن لم يكن للتطبيق طريقة يرفض بها العمل، فخيارك الوحيد إبقاء العميل القديم عاملًا إلى الأبد — أي أن الواجهة البرمجية لا يمكن أن تتغيّر أبدًا.
لذلك يسأل التطبيق الخادم عند التشغيل إن كانت نسخته لا تزال مدعومة، فيجيبه الخادم بحدّ أدنى للنسخة وبرسالة. بناء ذلك يكلّف بعد ظهر واحد والأحوال هادئة، ويستحيل بناؤه في اللحظة التي تحتاجه فيها فعلًا.
أصدر واجهتك البرمجية بنسخ من الإطلاق الأول
عميل الويب يُحدَّث مع الخادم، أما عميل الهاتف فلا: الناس يشغّلون نسخة العام الماضي، وبعضهم لن يحدّث أبدًا. ومن الإطلاق الأول فصاعدًا، كل نسخة أطلقتها يومًا هي عميل ما زلت تدعمه.
وهذا يجعل ترقيم نسخ الواجهة البرمجية ليس ترفًا بل الشيء الذي يتيح لك تغيير أي شيء أصلًا. تغييرات إضافية فقط داخل النسخة، ونسخة جديدة لأي تغيير كاسر، ومدة إيقاف تُقاس بسرعة ترقية مستخدميك الفعلية لا بالسرعة التي تتمنّاها.
خصّص ميزانية للتغيّر السنوي
كل من المنصتين يصدر نسخة نظام رئيسية سنويًا، ويوقف واجهات برمجية، ويرفع الحد الأدنى لحزمة التطوير التي يمكن التقديم بها، ويغيّر شروط المتجر: إفصاحات الخصوصية، وتبريرات الصلاحيات، وإقرارات التتبع. ولا شيء من ذلك اختياري، ولا شيء منه يقدّم ميزة، ولهذا لا يدخل أي خارطة طريق.
والتطبيق الذي يُترك سنتين يحتاج عادة أسابيع عمل قبل أن يصبح تقديمه ممكنًا من أصله. وتخصيص حصة صيانة صغيرة كل سنة أرخص من مشروع الإنقاذ، وهو حديث أسهل بكثير أن يُجرى مسبقًا لا أثناء تجميد إصدار.
اختبر الاتجاهين قبل التقديم
في تطبيق ثنائي اللغة، نصف مساحة الإصدار هو النصف الذي لا تقرأه. غيّر لغة الجهاز إلى العربية وامشِ في المسار الحرج: هل ينعكس التصميم، وهل تذهب إيماءة الرجوع في الاتجاه الصحيح، وهل تُنسَّق التواريخ والأرقام كما يجب، وهل يُقطع شيء بسبب نص أطول من الإنجليزي.
وهذا يستحق قائمة تحقّق لا نوايا حسنة، لأنه دائمًا الشيء الذي لم ينظر إليه أحد، ودورة مراجعة في المتجر طريقة مكلفة لاكتشاف زرّ مقطوع.