صيانة Laravel ودعمه

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

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

ماذا يغطي

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

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

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

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

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

ماذا لا يغطي

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

كيف يجري

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

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

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

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

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

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

ماذا تتسلّم

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

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