استلام تطبيق Laravel قديم يبدأ بإثبات أي كود يعمل فعلاً وأين وكيف يُنشر، ثم بناء شبكة أمان قبل الترقية أو إعادة الهيكلة. كلمة «قديم» لا تعني أن النظام سيئ، وقد يكون مستقراً في أعمال حساسة؛ لكنها تعني أن الاعتماديات والمعرفة والاختبارات والتشغيل تحتاج جرداً قائماً على الأدلة.
هذا الدليل فحص تقني عميق لتطبيق Laravel موروث. وهو مختلف عن دليل استلام برنامج من مزود آخر، الذي يركز على العقد والحسابات وخروج المورد واستمرارية العلاقة عبر أي تقنية. نفذ الانتقال المؤسسي أولاً، ثم استخدم هذه القائمة داخل المستودع والبيئات.
اثبت نقطة الإنتاج
حدد المستودع والفرع والالتزام أو الوسم الذي بُني منه الإنتاج. قارن ملفات البناء وcomposer.lock وpackage-lock أو ما يعادله وإعدادات النشر. لا تفترض أن الفرع الرئيسي يطابق الخادم؛ قد توجد تعديلات يدوية أو أصول مبنية لم تُدفع.
سجل إصدار PHP وLaravel والخادم والامتدادات وقاعدة البيانات وRedis ومدير العمليات وNode. اجمعها بأوامر قراءة فقط ولا تغير الإنتاج. أي فرق بين الوثائق والواقع يصبح مخاطرة يجب حلها عبر Git ونشر مضبوط، لا نسخ ملفات مباشرة.
أنشئ بيئة محلية قابلة للتكرار
ابدأ من نسخة مستودع نظيفة وملف بيئة مثالي بلا أسرار. وثق الخدمات والإضافات والبيانات التجريبية. لا تنقل قاعدة إنتاج إلى جهاز. أنشئ seed أو عينة منزوعة الهوية تغطي الأدوار والمسارات.
شغّل التثبيت والبناء والاختبارات من الصفر. إذا احتاجت الخطوات إلى ملف شخصي أو مفتاح مطور، سجل الاعتماد وأزل الربط. الهدف أن يستطيع عضو ثانٍ تشغيل المشروع من التعليمات نفسها.
اقرأ composer.json وملف القفل معاً
حدد إصدار Laravel وPHP والحزم المباشرة والمتروكة والمقيدة بإصدارات قديمة. لا تشغل تحديثاً شاملاً. استخدم أدوات Composer لعرض سبب تثبيت إصدار أو منع ترقية، وراجع إرشادات Laravel الرسمية لكل قفزة.
تحقق من المستودعات الخاصة وscripts وplugins. لا تمنح plugin غير موثوق صلاحية تلقائية. احتفظ بنسخة القفل وغيّر حزمة واحدة أو مجموعة مترابطة في فرع مع اختبارات وخطة رجوع.
شغّل اختبارات الخط الأساس وسجل الفشل
افصل فشلاً موجوداً عن فشل قدمه الفريق. شغّل Pest أو PHPUnit بإعداد موثق، ثم التحليل الساكن والتنسيق والبناء. لا تصلح عشرات الاختبارات بتغيير التوقعات حتى تصبح خضراء؛ افهم هل السلوك الحالي صحيح.
إذا كانت التغطية ضعيفة، فابدأ باختبارات توصيف السلوك الحالي للمسارات الحرجة: تسجيل الدخول، والصلاحيات، وعملية مالية، ومهمة، وتكامل. تثبت هذه الاختبارات ما يحدث قبل التعديل من دون أن تزعم أن التصميم الحالي مثالي.
ارسم مسار الطلب
ابدأ من routes إلى middleware وForm Requests والسياسات والمتحكمات والخدمات والنماذج والأحداث والوظائف. ابحث عن منطق عمل في Blade أو Vue أو observers أو accessors. سجل الحدود والتكرار ولا تبدأ نقله فوراً.
اختبر CSRF والمصادقة والجلسات وتحديد المعدل ومعالجة الاستثناءات. راجع المسارات غير المسماة أو التجريبية وواجهات debug. أي مسار إداري يحتاج تفويضاً من الخادم لا إخفاء رابط.
راجع قاعدة البيانات قبل ترحيلات جديدة
قارن migrations بالمخطط الفعلي بطريقة آمنة. قد تكون هناك جداول أو فهارس أو أنواع لا تمثلها migrations. لا تعِد تشغيل تاريخ قديم على الإنتاج. أنشئ baseline أو خطة تصحيح مدروسة بعد التحقق.
راجع المفاتيح الخارجية والفهارس والقيم nullable وحقول الحالة والتواريخ والمنطقة الزمنية. ابحث عن معرفات متعارضة وحذف cascade خطر. اختبر النسخ والاستعادة قبل أي تغيير مخطط.
افحص النماذج والتفويض
راجع $fillable و$guarded وcasts والخصائص المخفية والعلاقات وscopes والحذف الناعم. لا تعتبر mass assignment طبقة تفويض. يجب أن تمر العمليات بسياسة أو خدمة تتحقق من الممثل والسجل والحالة.
اختبر IDOR بتبديل المعرفات، خاصة التنزيل والتصدير والعلاقات المتداخلة. إذا كان التطبيق SaaS، استخدم دليل اختبار عزل المستأجرين لفحص السياق والطوابير والملفات، لا tenant_id فقط.
افهم الطوابير والجدولة
اجرد connections وqueues والعمال والمهام وtimeouts وtries وbackoff وfailed jobs وHorizon إن وجد. حدد الوظائف غير idempotent التي قد تكرر دفعاً أو إشعاراً عند retry. اختبر ماذا يحدث إذا مات العامل بعد أثر خارجي وقبل تحديث الحالة.
راجع Scheduler وcron والمنطقة الزمنية ومنع التداخل والعمل على خادم واحد. مهمة يومية قد لا تعمل منذ أشهر من دون تنبيه. أضف مراقبة لعمر الطابور والفشل والجدول، لا مجرد عملية عاملة.
راجع التخزين المؤقت والجلسات
حدد store وprefix وTTL ومفاتيح cache وهل تحمل مستأجراً أو مستخدماً. ابحث عن rememberForever وعمليات مسح واسعة. لا تستخدم flush في نشر اعتيادي إذا كانت الجلسات في Redis نفسه. اختبر invalidation بعد التعديل.
راجع cookie domain وSameSite وsecure ومدة الجلسة وتدويرها عند الدخول. لا تغير APP_KEY؛ ذلك قد يبطل بيانات مشفرة وجلسات. تأكد من إدارة المفاتيح والنسخ القديمة وفق خطة.
افحص الملفات والبريد والتكاملات
حدد disks وvisibility والروابط الموقعة والملفات المؤقتة ومعالجة الصور. حاول تنزيل ملف بلا صلاحية. راجع البريد والإشعارات والقوالب والصفوف الفاشلة. لا ترسل رسائل حقيقية من بيئة الاختبار.
لكل API خارجي، سجل المصادقة والمهلة وإعادة المحاولة وidempotency والتحقق من التوقيع والبيئة. افصل مفاتيح sandbox عن production. راجع دليل الويب هوك الموثوق قبل لمس callback مالي.
راجع الأسرار والتسجيل
ابحث عن أسرار في Git والسجلات وملفات البناء، لكن لا تطبعها في تقارير. إذا وُجد تسرب، دوّر السر ونظف الاستخدام بخطة؛ حذف السطر من آخر commit لا يمحوه من التاريخ. استخدم مدير أسرار أو إعداد خادمي مناسب.
افحص ما تسجله الاستثناءات والطلبات والمهام. احجب كلمات المرور والرموز والحمولات الحساسة. أضف correlation IDs وسياقاً آمناً. لا تجعل معالجة الخطأ تعرض stack trace في الإنتاج.
قيّم الواجهة والبناء
حدد Vite أو Mix وإصدارات Node والحزم والقفل والأصول المصدرية. شغّل build نظيفاً. راجع ما إذا كانت ملفات مبنية مخزنة في Git ولماذا. لا تغير bundler مع ترقية Laravel في خطوة واحدة إذا أمكن فصل المخاطر.
اختبر SSR إن وجد، وRTL، وإمكانية الوصول، وحالات الخطأ، وسياسة cache للأصول. لا تطارد درجة أداء قبل قياس المسارات الفعلية. ثبت سلوكاً أساسياً ثم نفذ تحسيناً واحداً.
افهم النشر والتراجع
اكتب الخطوات الحالية من pull وبناء وmigrate وcache وworkers وPHP-FPM وSSR. حدد أي خطوة تسبب توقفاً أو تسجيل خروج. اختبر --pretend أو rehearsal للمهاجرات الخطرة في نسخة محمية. لا تشغل migration طويلة بلا قياس وخطة.
يجب أن يكون التراجع أكثر من checkout؛ قد توجد قاعدة بيانات ورسائل ووظائف غير متوافقة. استخدم تغييرات توسعية ثم انتقالاً ثم إزالة في إصدار لاحق. راجع دليل النسخ الاحتياطي واستمرارية الأعمال لإثبات الاستعادة.
خطط الترقية على قفزات صغيرة
اقرأ دليل الترقية الرسمي لكل إصدار مستهدف، وحدد تغييرات framework والحزم وPHP. لا تقفز قبل أن تعمل اختبارات الخط الأساس. رقِّ PHP أو Laravel أو الواجهة في خطوات قابلة للقياس عندما تسمح الاعتماديات.
استخدم فرعاً قصيراً ومراجعة ونشراً مرحلياً. راقب الأخطاء والطوابير والاستجابة بعد كل قفزة. لا تخلط إعادة تسمية واسعة أو نمط معماري جديداً مع تحديث ضروري للأمان.
سلّم تقريراً مرتباً لا قائمة ذعر
قسّم النتائج إلى خطر فوري، وموثوقية تشغيل، وعائق ترقية، ودين قابل للجدولة، وتحسين. لكل نتيجة دليل وأثر وخيار واختبار وتكلفة تقديرية بعد الاكتشاف. لا تستخدم عدد التحذيرات وحده لترتيب العمل.
تقدم خدمة صيانة الأنظمة مالكاً تجارياً لهذا المسار، لكن يجب أن يبقى التقرير قابلاً للتنفيذ من أي فريق. اربط كل إصلاح بتذكرة ومعيار قبول وقرار نشر.
الخلاصة: ابنِ خط أساساً قبل تحديث أول حزمة
استلام Laravel قديم ينجح عندما تستطيع إعادة البيئة وتشغيل الاختبارات وتفسير الطلب والبيانات والطوابير والنشر والتراجع، ثم ترقية خطوة واحدة بدليل. لا تبدأ بـcomposer update شامل. اطلب فحص استلام تطبيق Laravel مع نسخة مستودع مصرح بها ومخطط بيئة منزوع الأسرار ومسارين حرجين.
