الترحيل من PHP القديم إلى Laravel

تطبيق كُتب بـ CodeIgniter عام 2014، أو بـ Zend، أو بـ Symfony 2، أو بلا إطار أصلًا - لا يزال يعمل، ولا يزال يدرّ مالًا، وصار الآن مكلفًا بطريقة محددة. لا أحد يلمسه، ومن كتبوه رحلوا، وإصدار PHP الذي يحتاجه خرج من الدعم.

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

لماذا إعادة الكتابة هي المخاطرة

إعادة الكتابة تعني بناء نظام ثانٍ بجانب الأول والتبديل حين ينتهي. ويترتب على ذلك ثلاثة أمور، وكلها متوقعة.

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

القواعد هي المشكلة. النظام الذي عمل عقدًا يحمل قرارات لا توجد في أي مكان آخر: لماذا تلك الفئة من العملاء معفاة، ولماذا يعمل التصدير الساعة 03:40، ولماذا يُتجاهل حقل سعر واحد. إعادة الكتابة تجدها شكوى تلو أخرى.

النقل مسارًا مسارًا بدل ذلك

ضع موجّهًا أمام النظامين. يرسل كل طلب إلى التطبيق الذي يملك ذلك المسار حاليًا - Laravel لما انتقل، والتطبيق القديم لكل ما عداه.

location /account/ { proxy_pass http://laravel; }
location /         { proxy_pass http://legacy; }

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

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

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

الأجزاء الصعبة فعلًا

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

تجزئات كلمات المرور القديمة. لا يمكنك تحويل ما لا تستطيع قراءته. يتحقق Laravel من الخوارزمية القديمة عند تسجيل الدخول ويعيد التجزئة عند النجاح، فتحوّل قاعدة البيانات نفسها بنفسها مع دخول الناس بدل رسالة إعادة تعيين تُرسل للجميع دفعة واحدة.

جداول شكّلها ORM النظام القديم. مفاتيح مركّبة، وبلا طوابع زمنية، ومفتاح أساسي باسم آخر، وقيمة منطقية مخزَّنة كـ 'Y'. تُضبط نماذج Eloquent على تلك الجداول بدل تغيير الجداول لتناسب Eloquent - ذلك يأتي لاحقًا، إن أتى.

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

ما لا نفعله

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

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

كيف يجري التعاقد

أول ما نحتاجه جدول المسارات لما هو قائم الآن، وجواب صادق عن الأجزاء التي لم يعد أحد يفهمها.

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

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

ماذا تتسلّم

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

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