ترقيات Laravel وإنقاذه

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

كلتاهما قابلة للمعالجة. ولا تتطلب أي منهما إعادة كتابة عادةً.

الترقيات، إصدارًا إصدارًا

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

وما يجعله آمنًا ترتيبُ العمل:

1. التغطية قبل الحركة. اختبارات توصيف على المسارات والمهام المهمة، تؤكد ما يفعله التطبيق اليوم، صوابًا كان أم خطأ. بدون هذا تكون الترقية سلسلة تغييرات بلا وسيلة لمعرفة هل كسرت شيئًا.
2. PHP بجانب Laravel. يتحرك القيدان معًا، ورسم الاعتماديات يقرر الترتيب عادةً. الحزمة التي لا إصدار لها لنسخة PHP المستهدفة تُكتشف الآن لا بعد ثلاثة إصدارات.
3. إصدار واحد لكل فرع، مدموج. كل خطوة تُنشر وحدها، لتكون الانتكاسة منسوبة إلى تغيير واحد لا إلى أربعين.
4. الاعتماديات تُدقَّق لا تُرفَع عشوائيًا. الحزمة المهجورة قرار - استبدلها، أو ضمّها إلى مستودعك، أو اقبلها - وذلك القرار أرخص إذا اتُّخذ عمدًا من أن يتخذه بناء منهار في منتصف الليل.

الجزء الأطول عادةً ليس الإطار. بل الحزم المحيطة به، وتحديدًا تلك التي هُجرت في مكان ما بين إصدارك والإصدار الحالي.

الشيفرات الموروثة

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

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

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

ما نجده، في كل مرة تقريبًا

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

ملف .env هو التوثيق الوحيد للبنية التحتية. خدمات لا يعرف أحد أسماءها، وبيانات اعتماد لم يدوّرها أحد، وقيمة واحدة على الأقل يعتمد عليها كل شيء وغير موثَّقة.

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

بيئة اختبار لا تطابق الإنتاج في البعد الوحيد الذي يهم: حجم البيانات عادةً، وأحيانًا إصدار PHP.

ما الذي يمسك العمل معًا

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

كل خطوة قابلة للنشر. لا فروع طويلة العمر. وإن تغيّرت الأولويات وتوقف العمل ربع سنة، يكون المدموج متماسكًا ويكون الباقي قائمة لا تعارضًا.

الحالة النهائية مكتوبة. الترقية بلا خط نهاية مدوَّن تصير، بعد تغيير موظف واحد، شيفرةً لا يعرف أحد أي عُرف فيها هو الساري.

متى يكون التدقيق خطوة أولى أفضل

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

كيف يُحدَّد النطاق

نقرأ التطبيق أولًا: الإصدار، والحزم التي لا بديل مصان لها، وما تغطيه الاختبارات فعلًا، وكم تحرّك إطار العمل تحته.

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

يبدأ العمل بعد التوقيع. إصدارًا واحدًا في كل مرة، وكل خطوة في طلب دمج خاص بها.

ماذا تتسلّم

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

وتتسلّم أيضًا قائمة بما تركناه عمدًا: حزم لا بديل مصان لها، وشيفرة تعمل ولا ينبغي المساس بها بعد، وكم سيكلّف كلٌّ منها حين يحين وقته.