"بضع مرات" كان علي التعامل مع ترحيل المشاريع من yii1 إلى yii2 وأريد مشاركة تجربتي مع المجتمع. لا يوجد شيء معقد في هذه العملية ولن يكون هناك كشف. طبيعة المنشور هي تجربتك + دروس للمبتدئين.
الخلفية
إذا استمرت المشاريع التي تم إجراؤها تاريخياً في الإصدار الأول من yii في التطور ، فإن كل مطور يعمل معهم عاجلاً أم آجلاً يتوصل إلى فكرة: "
كم سيكون الأمر جيدًا إذا كان على yii2 ".
لكن الأشياء عادة لا تتجاوز الأفكار ، لأن يبدو حجم العمل هائلاً. بشكل عام ، كما هو ، الحجم ضخم ، لكنه لا يزال غير محظور - وفقًا للمثل "العيون خائفة". بالإضافة إلى ذلك ، للانتقال إلى العمل ، هناك حاجة إلى قوة إرادة معينة (أنا داخليًا ، كنت أستعد لترحيل المشروع الأول لمدة عام تقريبًا).
فكرتي للهجرة تحت القط.
قبل "إظهار الرمز" ، سأكتب الكثير من الحروف "لماذا فعلت ذلك" ، لأن أسباب تحدد طبيعة العمل. كان لدي حالتان مماثلتان.
في المشروع الأول ، كان كل شيء بسيطًا. أنا مالك مشارك والمطور الوحيد. لذلك ، السبب "لقد سئمت من الكتابة في yii1" مقنع للغاية. يجب أن تكون الكتابة "عالية" ، وإلا فقد تكون النتيجة سيئة الجودة.
في الحالة الثانية ، أنا مقاول في مشروع كتبه العديد من المطورين لفترة طويلة بدون بنية واضحة. لذلك ، كان الناتج مجموعة ضخمة من التعليمات البرمجية القديمة. من السهل إعادة الكتابة بهذه الطريقة لإقلاع
نفسك عن الإقلاع عن التدخين ، ولا يتعرف العميل على إعادة الهيكلة من أجل إعادة الهيكلة ، لذلك زاد كل مطور جديد من الكومة بشكل أكبر.
الوضع في حالة جمود: الجميع يفهم أن هناك مشكلة في الكود لكنهم لا يستطيعون الخروج من هذه الدائرة. اقترحت الهجرة المعيارية التدريجية إلى yii2. بعد 1.5 شهر ، بدأ جزء من الموقع في العمل على yii2 ، مما يعني أن هناك مكانًا للهجرة وبنية تحتية حيث يمكنك العمل بشكل مفيد. بالطبع ، يمكنك الاستمرار في الكتابة بشكل سيئ ، ولكن لم يعد بإمكانك تبرير نفسك بـ "نظرة على ما هو الرعب من حول".
فكر قبل أن تبدأ
بالنسبة لي ، لقد حددت عدة قواعد. إذا بدأت عملية الترحيل ، فيجب إما احترامها أو عدم بدءها.
- من الضروري فهم وقبول "لماذا نحتاج إلى البواسير". يمكن أن يكون هناك أي دافع ، ولكن يجب أن يفوق كل العيوب بهامش كبير.
- يجب ألا تبدأ الترحيل إذا لم يكن للمشروع مستقبل واضح في التوقعات لمدة 2-3 سنوات مقدمًا. أو تفعل ذلك من أجل المتعة.
- نكتب كل الوظائف الجديدة ، كل التطوير ، كل جديد على yii2. في yii1 ، يجب أن يبقى الدعم فقط. إذا لم يتم اتباع هذه القاعدة ، فستتلقى على الفور فرعين نشطين ، الأمر الذي سيتطلب موارد أكثر مرتين. وبما أنه لا توجد دائمًا موارد كافية ، فقد ينتهي كل هذا.
- لا تقم بتعيين المهمة "إعادة كتابة كل ما هو بغباء". إن "إعادة كتابة كل شيء" مجردة ومملة للغاية لدرجة أنك إذا قمت بصوتها لفريقك في هذه الصياغة ، فعندئذ في وجوههم الحزينة ، يمكنك قراءة الكثير من الأشياء المثيرة عنك.
- لأن حتى إذا لم يكن من الممكن إعادة كتابة "كل ما تريده" على الفور ، فأنت بحاجة إلى خطة للترحيل التدريجي - من خلال الصفحات أو الخدمات أو الوحدات.
- اهم شيء! من الأفضل اعتبار الهجرة إلى yii2 بمثابة إعادة هيكلة عميقة للمشروع بأكمله الذي يهدف إلى التنمية. ثم قد يتبين أن ثلث المشروع لا يحتاج إلى إعادة الكتابة على الإطلاق (إذا كان يعمل بشكل جيد "كما هو" ولا يتطلب سوى الحد الأدنى من الدعم) ، ويمكن دفن جزء من المشروع بشكل جميل. على سبيل المثال ليس فقط قتل الخدمات / الصفحات ، ولكن أيضًا إعادة المشروع بحيث لا تكون هناك حاجة إليه ببساطة.
فكرة الهجرة
فكرتي عن الترحيل هي التعاون المتزامن لفرعين من نفس المشروع على yii1 و yii2 في نفس المجال ، على نفس المضيف الظاهري. تدريجيا ، خدمات / صفحات / وحدات المنفذ خطوة بخطوة إلى yii2.
على سبيل المثال ، هناك موقع يعمل على yii1
site.ru/ # site.ru/news # site.ru/pages # site.ru/comments #
قمنا بنسخ الأخبار على yii2 ، وتلقى:
site.ru/ # site.ru/news # (yii2) site.ru/pages # site.ru/comments #
التعليقات المكتوبة ، وردت
site.ru/ # site.ru/news # (yii2) site.ru/pages # site.ru/comments # (yii2)
وبالتدريج ، صفحة تلو الأخرى ، حتى نعيد كتابة كل ما نريد إعادة كتابته. من الواضح أنه كلما قمنا بإعادة كتابة النص ، كلما كانت العملية أسهل. الأصعب دائمًا هو الخطوة الأولى: الصفحة الأولى ، الوحدة الأولى ، الخدمة الأولى.
الجزء الأول فقط للعمل في نفس الوقت
سأضيف حشوات ، ولكن كل شيء بسيط حقًا. في أبسط الحالات ، احتفظ بالفرعين (yii1 و yii2) في نفس مساحة العمل ، كما يلي:
/var/www/site/htdocs/ - DOCUMENT_ROOT /var/www/site/yii1/ - yii1 /var/www/site/yii2/ - yii2
أو هكذا /var/www/site/public_html/ - DOCUMENT_ROOT /var/www/site/protected/ - yii1 /var/www/site/yii2/ - yii2
أو نحو ذلك
/var/www/site/ - DOCUMENT_ROOT /var/www/site/protected/ - yii1 /var/www/site/yii2/ - yii2
لا يهم كيفية تسمية الدلائل ووضعها. من الضروري التأكد من أن الكود الموجود على yii1 و yii2 يقعان في مكان قريب ومتاحان للعمل في مضيف افتراضي واحد. وكل سحر العمل المتزامن سيكون في فهرس نصوص الإدخال. php و. htaccess.
ما هي مزايا هذا النهج:
- في بيئة التطوير الخاصة بك ، سيتوفر فرعين للمشروع على الفور. يمكن أن تكون مريحة ، لأن لفترة طويلة عليك العمل معهم في نفس الوقت ، التبديل ذهابًا وإيابًا.
- سيحصل كلا المشروعين على وصول مباشر إلى DOCUMENT_ROOT ، وهو أمر مهم للعمل البسيط مع إحصائيات css / js.
يمكن أن تكون السلبيات جمالية (حسب النوع: ما يعيق التدخل جميعًا معًا) ، ومرتبطًا بعمل متعدد المستخدمين. نعم ، يمكنك تقسيم مواقع تخزين التعليمات البرمجية وتقسيم المشاريع في بيئة تطوير. هذا لا يغير الجوهر ، فقط أضف الفروق الدقيقة.
أنا شخصياً أنشأت مشروعًا منفصلاً لفرع yii2 في IDE ، حتى عندما كانت ملفات الفرع موجودة فعليًا في مكان قريب.
مثال أساسي. مصادر فروع مشروع yii1 / yii2 في دليل واحد
يستخدم DOCUMENT_ROOT نصين إدخال.
index.php - yii1 index_yii2.php - yii2.
في هيكل الملف htdocs/ htdocs/index.php htdocs/index_yii2.php yii1/ yii2/
index.phpإذا لم تقم بتغيير بنية الملف للمشروع إلى yii1 ، فسيظل index.php دون تغيير.
على سبيل المثال <?php $app = Yii::createApplication('WebApplication', $config); $app->run(); ?>
index_yii2.php <?php defined('YII_DEBUG') or define('YII_DEBUG', true); defined('YII_ENV') or define('YII_ENV', 'dev');
.htaccessفي htaccess ، سنجري التوجيه بين yii1 و yii2
Options +FollowSymlinks RewriteEngine On RewriteBase / # yii2 # # RewriteRule ^test index_yii2.php [L] RewriteRule ^news index_yii2.php [L] # action RewriteRule ^page/one index_yii2.php [L] # RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d # yii1 RewriteRule . index.php
على سبيل المثال تتم معالجة عناوين URL التالية بواسطة index_yii2.php وتشغيلها على yii2.
https://site/test https://site/news https://site/page/one
باقي الموقع هو index.php (yii1).
هذا إطلاق متزامن أساسي. بالطبع ، سيكون لكل منها فروق دقيقة خاصة به: فريق ، مستخدمين ، حقوق وصول ، خوادم ، مستودعات مختلفة ، إلخ. وسيكون لكل شخص حديقته الخاصة.
يتم توزيع الرموز المصدر لفروع yii1 / yii2 في الدلائل
على سبيل المثال ، إذا كان لديك خادمك الخاص ، فيمكنك نشر تخزين فروع المشروع في أدلة مختلفة.
/var/www/site/htdocs - DOCUMENT_ROOT site.ru /var/www/site/protected - yii1 /srv/site_yii2 - yii2
ثم تحتاج إلى تغيير المسار إلى الدليل باستخدام المشروع yii2 في index_yii2.php. بالطبع ، سيعمل هذا إذا تم تعطيله ، أو تم تكوين open_basedir. بالإضافة إلى الحقوق المطابقة على الخادم والمعطل / تكوين SELinux.
index_yii2.php <?php defined('YII_DEBUG') or define('YII_DEBUG', true); defined('YII_ENV') or define('YII_ENV', 'dev'); $pathYii2 = '/srv/site_yii2/'; require $pathYii2 . 'vendor/autoload.php'; require $pathYii2 . 'vendor/yiisoft/yii2/Yii.php'; require $pathYii2 . 'common/config/bootstrap.php'; require $pathYii2 . 'frontend/config/bootstrap.php'; $config = yii\helpers\ArrayHelper::merge( require $pathYii2 . 'common/config/main.php', require $pathYii2 . 'common/config/main-local.php', require $pathYii2 . 'frontend /config/main.php', require $pathYii2 . 'frontend /config/main-local.php' ); (new yii\web\Application($config))->run();?>
ما هي الخطوة التالية
إذا كان هناك مستخدمون على الموقع ، إذن إذن واحد هو عنصر حاسم بدونه ، في الواقع ، من المستحيل تشغيل فرعين في وقت واحد. أخطط في المقالة التالية لإظهار مدى سهولة تنظيم تفويض واحد. على سبيل المثال ، يظل التفويض نفسه في yii1 ، ولكن يمكن رؤية المستخدمين المصرح لهم بشفافية في فرع yii2 أو العكس.