الجواب باختصار.
كان أي تغيير في db/prod.sql، الملف الذي يجهّز الجداول المهيأة للقراءة، يشغّل سلسلة البيانات كلها: إعادة بناء الجداول، نشرها على Hugging Face، إعادة بناء صورة قاعدة البيانات، ثم الصورتين المبنيتين فوقها. أربعة تغييرات من هذا النوع في 9 تشرين الثاني احتاج كل منها نحو ساعة ونصف من الدمج إلى الموقع الحي. صارت السلسلة تنظر في ما غيّره الدفع. وآخر تغيير في ذلك اليوم صار حياً بعد 28.5 دقيقة من دمجه.
أين ذهبت الدقائق الـ90.
بالقياس على تشغيل واحد: البناء 6 دقائق، النشر 31، صورة قاعدة البيانات 12، و5 لكل من الصورتين فوقها. أمضى النشر 30 من دقائقه الـ31 في انتظار تشغيل للمتجهات لا يبدأ إلا عند تغيّر البيانات. ثم سجّل جداول لم تتغيّر على Hugging Face، وهذا يعيد تشغيل عارض البيانات هناك لنحو 33 دقيقة.
بناء ما تغيّر فقط.
مهمة أولى جديدة تقارن الدفع بالإيداع الذي سبقه. إذا لم يتغيّر شيء تحت data/ تُتخطى مهام البناء والنشر وصورة قاعدة البيانات، وتُبنى الصورة المهيأة للقراءة فوق صورة قاعدة البيانات المنشورة أصلاً لتلك البيانات. وعند الشك، في تشغيل يدوي أو إيداع مفقود أو مقارنة فاشلة، يُعدّ الدفع تغييراً في البيانات ويُشغَّل كل شيء. وصار النشر ينتظر 3 دقائق لظهور تشغيل للمتجهات، لا 30.
الدليل.
دمجنا تعليقاً من سطر واحد في db/prod.sql لنقيس. استغرق تشغيل البيانات 9 دقائق و34 ثانية: 7 ثوانٍ للمقارنة، و5 دقائق و11 ثانية للصورة المهيأة للقراءة، و4 دقائق و8 ثوانٍ للصورة الشاملة. لم يصل أي إيداع إلى Hugging Face. أعلن الموقع عن البناء الجديد بعد 43 دقيقة و39 ثانية من الدمج، ونحو 25 دقيقة منها كانت بسبب المهلة الموصوفة في الفقرة التالية.
مهلة أقصر من الانتظار الذي بداخلها.
تنتظر مهمة التجهيز في النشر حتى 30 دقيقة ليكمل Cloudflare تجهيز الجهة غير المستخدمة، لكن المهمة نفسها كانت تُلغى بعد 15. استغرق التجهيز في ذلك اليوم 14 دقيقة و17 ثانية، ثم 6 دقائق و7 ثوانٍ، ثم أكثر من 15، فاحتاج ذلك النشر إلى إعادة تشغيل يدوية. صارت مهلة المهمة 40 دقيقة.
الشيفرة الجديدة لا تلتقي بقاعدة البيانات القديمة.
في 7 تشرين الثاني أطلق تغيير واحد في الشيفرة والبيانات عمليتَي نشر: واحدة بعد الفحوص التي تستغرق 5 دقائق وأخرى بعد بناء البيانات الذي يستغرق 40. جهّزت الأولى الشيفرة الجديدة على قاعدة البيانات القديمة، فتلقّت طلبات تسخينها أخطاء طوال 24 دقيقة إلى أن حلّت الثانية محلها. الإصلاح الأول كان يبحث عن بناء بيانات على الإيداع نفسه. لكن دمجه هو، وكان إيداعاً يخص CI وحده وصل بعد 3 دقائق من تغيير في المخطط، أفلت منه. صار النشر ينتظر أي بناء بيانات ما زال جارياً. في الحالتين لم يرَ الأخطاء إلا طلبات التسخين التابعة لنا: لم يتلقَّ الزوار أي خطأ في ذلك اليوم.
فحوص تُحتسب فحوصاً.
ملف في المستودع، livecheck.yaml، يحدد ما يجب أن يظهره الموقع الحي: الصفحة الرئيسية، صفحة قانون، واجهة البحث البرمجية، تطابق البناء المنشور مع الفرع الرئيسي، وستة طلبات MCP متزامنة. فحوصنا وطلبات النشر التابعة لنا تعرّف عن نفسها، ويستثنيها الموقع من مخططات زمن الاستجابة. قبل ذلك كانت طلباتها السريعة ستجعل الأرقام تبدو أفضل مما يحصل عليه الناس، وطلب تسخين بطيء واحد على حاوية باردة أطلق تنبيهاً عند 2,627 ميلي ثانية لم يشعر به أي زائر.