أحد عشر منتجًا، ونظام إنتاج واحد، والترتيب الذي نقرأ به الأدلّة

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

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

قاعدتان تجعلان الأتمتة قابلة لإعادة التشغيل

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

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

الخلل الذي ليس عيبًا

في 30 سبتمبر أصبح منتجان متاحين على App Store. كان هذا الموقع يقول إن أحدهما في مرحلة بيتا وغير مُدرَج علنًا في أيٍّ من المتجرين. لم يكن في هذا المستودع شيء خطأ، ولم تكن أي مراجعة قادرة على اكتشافه، لأن الإطلاق حدثٌ يقع خارج المستودع: لا يتغيّر ملف، فلا فرقَ يُقرأ ولا اختبارَ يمكن أن يسقط.

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

أيّ مستند يُصدَّق

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

Veyra هو المثال المشروح. كانت صفحته على هذا الموقع تقول إن التوليد لم يعمل قط وإن أوزان أي نموذج لم تُحمَّل قط. جاء ذلك من مستند حالة ومن readme، كلاهما بتاريخ 11 سبتمبر، وتكرّر هنا أسبوعين. وفي الوقت نفسه، في المستودع ذاته، كان هناك ملف مسحوب من هاتف فعلي يسجّل عمليتي توليد حقيقيتين: أربعة مرشّحين في كل منهما، وكل صورة بمقاس مختلف، موسومة بالنموذج الحقيقي، وأزمنتها مقروءة من قاعدة بيانات الجهاز نفسه. قلّلت الصفحة من قدر منتجها طيلة أسبوعين، وهو خلل ألطف من المبالغة، وهي صفحة خاطئة على كل حال.

لذلك كُتب الترتيب، ولا تتجاوز رتبةٌ أدنى رتبةً أعلى، مهما كانت الأدنى حديثة الكتابة ومهما صيغت بثقة:

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

هذا الترتيب ليس حكمًا على من يكتب بعناية. إنه حكم على ما يتعفّن. بيانات المتجر تتغيّر عندما يتغيّر المنتج؛ وملف readme يتغيّر عندما يتذكّر أحدهم.

ما الغرض الحقيقي من نظام مشترك

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