एक समय की नौकरी के माध्यम से yii1 से yii2 के लिए एक परियोजना की ओर पलायन

"एक दो बार" मुझे yii1 से yii2 तक परियोजनाओं के प्रवास से निपटना पड़ा और मैं समुदाय के साथ अपने अनुभव को साझा करना चाहता हूं। इस प्रक्रिया में कुछ भी जटिल नहीं है और कोई रहस्योद्घाटन नहीं होगा। प्रकाशन की प्रकृति शुरुआती के लिए आपका अनुभव + ट्यूटोरियल है।

आवश्यक शर्तें

यदि ऐतिहासिक रूप से yii के पहले संस्करण पर बनाई गई परियोजनाएँ विकसित होती रहती हैं, तो प्रत्येक डेवलपर जो उनके साथ जल्दी या बाद में काम करता है, इस विचार के साथ आता है: " अगर यह yii2 पर होता तो कितना अच्छा होता "।

लेकिन चीजें आमतौर पर विचारों से परे नहीं होती हैं, क्योंकि काम की मात्रा में भारी लगता है। सामान्य तौर पर, यह जिस तरह से है, मात्रा बहुत बड़ी है, लेकिन अभी भी निषेधात्मक नहीं है - नीतिवचन के अनुसार "आँखें डरती हैं"। इसके अलावा, कार्रवाई के लिए संक्रमण के लिए, एक निश्चित इच्छाशक्ति की आवश्यकता होती है (मैं, आंतरिक रूप से, लगभग एक वर्ष के लिए पहली परियोजना के प्रवास की तैयारी कर रहा हूं)।

मेरे प्रवास का विचार बिल्ली के नीचे है।

"कोड दिखाने से पहले" मैं बहुत सारे पत्र लिखूंगा "मैंने ऐसा क्यों किया", क्योंकि कारण कार्य की प्रकृति का निर्धारण करते हैं। मेरे पास 2 ऐसे ही मामले थे।

पहले प्रोजेक्ट में, सब कुछ सरल था। मैं सह-मालिक और एकमात्र डेवलपर हूं। इसलिए, कारण "मैं सिर्फ yii1 में लिखने से थक गया हूं" काफी सम्मोहक है। लेखन "उच्च" होना चाहिए, अन्यथा परिणाम खराब गुणवत्ता वाला बकवास हो सकता है ।

दूसरे मामले में, मैं एक परियोजना में एक ठेकेदार हूं जो विभिन्न डेवलपर्स द्वारा लंबे समय तक एक स्पष्ट वास्तुकला के बिना लिखा गया है। इसलिए, आउटपुट विरासत कोड का एक विशाल समूह था। इस तरह से पुनर्मिलन करना अपने आप को छोड़ने के लिए शूट करना आसान है, ग्राहक को फिर से तैयार करने के लिए पहचानना नहीं है, इसलिए प्रत्येक नए डेवलपर ने ढेर को और भी अधिक बढ़ा दिया है।

स्थिति गतिरोधी है: हर कोई समझता है कि कोड के साथ कोई समस्या है, लेकिन वे इस सर्कल से बाहर नहीं जा सकते। मैंने yii2 के क्रमिक मॉड्यूलर प्रवास का सुझाव दिया। 1.5 महीने के बाद, साइट का हिस्सा yii2 पर काम करना शुरू कर दिया, जिसका मतलब है कि माइग्रेट करने के लिए एक जगह है और एक बुनियादी ढांचा है जहां आप सार्थक रूप से काम कर सकते हैं। बेशक, आप खराब लिखना जारी रख सकते हैं, लेकिन अब आप अपने आप को "जिस डरावनी चीज के आस-पास देखो" के साथ खुद को औचित्य नहीं दे सकते।

शुरू करने से पहले सोचें

अपने लिए, मैंने कई नियमों की पहचान की है। यदि आप एक प्रवास शुरू करते हैं, तो या तो उनका सम्मान किया जाना चाहिए, या आपको इसे शुरू नहीं करना चाहिए।

1. यह समझना और स्वीकार करना आवश्यक है "हमें बवासीर की आवश्यकता क्यों है।" कोई भी प्रेरणा हो सकती है, लेकिन इसे बड़े अंतर के साथ सभी नुकसानों को दूर करना चाहिए।
2. यदि परियोजना 2-3 साल पहले ही पूर्वानुमान में स्पष्ट भविष्य में नहीं होती है, तो आपको प्रवास शुरू नहीं करना चाहिए। या आप इसे मजे के लिए करते हैं।
3. हम yii2 पर सभी नई कार्यक्षमता, सभी विकास, सभी नए लिखते हैं। Yii1 में, केवल समर्थन ही रहना चाहिए। यदि इस नियम का पालन नहीं किया जाता है, तो आप तुरंत 2 सक्रिय शाखाएं प्राप्त करेंगे, जिसके लिए 2 गुना अधिक संसाधनों की आवश्यकता होगी। और, चूंकि हमेशा पर्याप्त संसाधन नहीं होते हैं, तो यह सब समाप्त हो सकता है।
4. कार्य सेट न करें "मूर्खतापूर्ण सब कुछ है कि फिर से लिखना।" "सब कुछ फिर से लिखना" इतना सारगर्भित और उबाऊ है कि अगर आप इस शब्द को अपनी टीम के सामने रखते हैं, तो आप उनके बारे में बहुत सारी दिलचस्प बातें पढ़ सकते हैं।
5. क्योंकि यहां तक ​​कि अगर "सब कुछ आप चाहते हैं" को फिर से नहीं लिखा जा सकता है, तो आपको क्रमिक प्रवास की योजना चाहिए - पृष्ठों द्वारा, सेवाओं द्वारा, मॉड्यूल द्वारा।
6. सबसे महत्वपूर्ण बात! विकास के उद्देश्य से 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 

यह महत्वपूर्ण नहीं है कि निर्देशिकाओं का नाम और स्थान कैसे दिया जाए। यह सुनिश्चित करना आवश्यक है कि yii1 और yii2 पर कोड पास में स्थित है और एक वर्चुअल होस्ट में काम करने के लिए उपलब्ध है। और एक साथ काम करने का सारा जादू इनपुट स्क्रिप्ट्स index.php और .htaccess में होगा।

इस दृष्टिकोण के क्या लाभ हैं:

• आपके विकास के माहौल में, 2 परियोजना शाखाएँ तुरंत उपलब्ध होंगी। यह सुविधाजनक हो सकता है, क्योंकि लंबे समय तक आपको एक ही समय में उनके साथ काम करना होगा, आगे और पीछे स्विच करना होगा।
  
• दोनों परियोजनाओं में DOCUMENT_ROOT की सीधी पहुंच होगी, जो सीएसएस / जेएस स्टैटिक्स के साथ सरल काम के लिए महत्वपूर्ण है।

विपक्ष दोनों सौंदर्यवादी हो सकते हैं (प्रकार से: सभी में एक साथ हस्तक्षेप करने के लिए क्या बाधा है), और बहु-उपयोगकर्ता के काम से जुड़ा हुआ है। हां, आप कोड संग्रहण स्थानों को विभाजित कर सकते हैं और विकास के माहौल में परियोजनाओं को विभाजित कर सकते हैं। यह सार नहीं बदलता है, बस बारीकियों को जोड़ें।

व्यक्तिगत रूप से, मैंने IDE में yii2 शाखा के लिए एक अलग परियोजना बनाई, तब भी जब शाखा फाइलें भौतिक रूप से पास में पड़ी थीं।

मूल उदाहरण। एक निर्देशिका में yii1 / yii2 परियोजना शाखाओं के स्रोत

DOCUMENT_ROOT 2 इनपुट स्क्रिप्ट का उपयोग करता है।

 index.php -  yii1 index_yii2.php -  yii2. 

index.php
यदि आप प्रोजेक्ट के लिए फ़ाइल संरचना को yii1 में नहीं बदलते हैं, तो आपका index.php अपरिवर्तित रहेगा।


index_yii2.php

 <?php defined('YII_DEBUG') or define('YII_DEBUG', true); defined('YII_ENV') or define('YII_ENV', 'dev'); //     yii2  index_yii2.php, //      «». $path = '/../yii2/'; require(__DIR__ . $path.'vendor/autoload.php'); require(__DIR__ . $path.'vendor/yiisoft/yii2/Yii.php'); require(__DIR__ . $path.'common/config/bootstrap.php'); require(__DIR__ . $path.'frontend/config/bootstrap.php'); $config = yii\helpers\ArrayHelper::merge( require(__DIR__ . $path.'common/config/main.php'), require(__DIR__ . $path.'common/config/main-local.php'), require(__DIR__ . $path.'frontend/config/main.php'), require(__DIR__ . $path.'frontend/config/main-local.php') ); (new yii\web\Application($config))->run();?> 

.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 

फिर आपको index_yii2.php में प्रोजेक्ट yii2 के साथ निर्देशिका में पथ बदलने की आवश्यकता है। निश्चित रूप से, यह काम करेगा यदि यह अक्षम है, या open_badeir कॉन्फ़िगर किया गया है। साथ ही सर्वर और विकलांग / कॉन्फ़िगर, SELinux पर संबंधित अधिकार।

आगे क्या है

यदि साइट पर उपयोगकर्ता हैं, तो एकल प्राधिकरण एक महत्वपूर्ण तत्व है जिसके बिना 2 शाखाओं का एक साथ संचालन वास्तव में, असंभव है। अगले लेख में मैंने यह दिखाने की योजना बनाई है कि किसी एकल प्राधिकरण को व्यवस्थित करना कितना आसान है। उदाहरण के लिए, प्राधिकरण स्वयं yii1 में बना रहता है, लेकिन अधिकृत उपयोगकर्ता पारदर्शी रूप से yii2 शाखा या इसके विपरीत दिखाई देते हैं।