صيانة Laravel ودعمه

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

هذا هو الترتيب الذي يمنع ذلك، لأنشطة تطبيقُها مهم لكنه لا يبرر فريق Laravel دائمًا.

ماذا تغطّي صيانة Laravel ودعمها

ترقيعات أمنية، تُطبَّق فورًا. Laravel وPHP وشجرة اعتمادياتك كلها تنشر تحذيرات. أغلبها لا يعنيك وقليلها يعنيك، ومعرفة أيها أيها هي العمل. الترقيعات ضمن النطاق المدعوم تصدر وفق جدول؛ وأي شيء عاجل يصدر حين يُعلن لا في الإصدار المريح التالي.

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

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

شخص على الطرف الآخر. مسار إلى مهندس يعرف مخططك وطوابيرك ونشرك سلفًا، ليبدأ الحادث بالتشخيص لا بالتعرّف.

مراقبة لها معنى. المهام الفاشلة، وعمق الطابور، ومعدلات الأخطاء، ونقاط النهاية التي تحمل مالًا - مراقَبة، بعتبات متفق عليها معك، كي لا يكون أول بلاغ عن مشكلة عميلًا.

ماذا لا يغطي

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

كيف يجري، وما يفترضه عقد صيانة Laravel

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

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

كل شيء يحدث في مستودعك، كطلبات دمج قابلة للمراجعة. ولا يُفعل بنظامك شيء لا تستطيع قراءته بعد ذلك.

بماذا تلتزم نافذة دعم Laravel فعلًا

"مدعوم" تعني شيئين مختلفين، والفرق بينهما يحسم موعد جدولة الترقية الكبرى.

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

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

وعمليًا هذا يعني ورقة بثلاثة سطور والتاريخ التالي في كل سطر، تُراجَع كل ربع سنة بدل أن تُكتشَف. والمخرَج المفيد ليس التواريخ - بل أن تعرفوا في سبتمبر أن الترقية تنتمي إلى خطة يناير، وهي ما زالت اختيارًا في الموعد.

مُجدوِل Laravel والعامل الذي لا يراقبه أحد

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

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

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

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

متى يكون هذا الشيء الخطأ لشرائه

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

وإن لم يستطع أحد أن يقول هل التطبيق سليم، فإن التدقيق يجيب عن ذلك في أسبوعين بسعر ثابت، والجواب يقرر أي هذه التعاقدات تحتاج فعلًا.

ماذا تتسلّم من صيانة Laravel

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

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