Migration d'un projet de yii1 vers yii2 via un travail unique

«À quelques reprises», j'ai dû faire face à la migration de projets de yii1 à yii2 et je veux partager mon expérience avec la communauté. Il n'y a rien de compliqué dans ce processus et il n'y aura pas de révélations. La nature de la publication est votre expérience + tutoriel pour les débutants.

Contexte

Si les projets historiquement réalisés sur la première version de yii continuent d'évoluer, alors chaque développeur qui travaille avec eux tôt ou tard se pose la question: «à quel point ce serait bien si c'était sur yii2 ».

Mais les choses ne dépassent généralement pas les pensées, car la quantité de travail semble colossale. En règle générale, le volume est énorme, mais toujours pas prohibitif - selon le proverbe «les yeux ont peur». De plus, pour la transition vers l'action, une certaine volonté est nécessaire (je prépare en interne la migration du premier projet depuis près d'un an).

Mon idée de migration est sous cat.

Avant de "montrer le code", j'écrirai beaucoup de lettres "pourquoi ai-je fait cela", car des raisons déterminent la nature du travail. J'ai eu 2 cas similaires.

Dans le premier projet, tout était simple. Je suis à la fois copropriétaire et seul développeur. Par conséquent, la raison pour laquelle "je suis juste fatigué d'écrire en yii1" est assez convaincante. L'écriture doit être "élevée", sinon le résultat peut être une merde de mauvaise qualité.

Dans le second cas, je suis entrepreneur dans un projet qui a été écrit par différents développeurs depuis longtemps sans architecture claire. Par conséquent, la sortie était un énorme tas de code hérité. Une réécriture comme celle-ci est plus facile à tirer vous-même en quittant; le client ne reconnaît pas le refactoring pour le refactoring, donc chaque nouveau développeur a encore plus augmenté le tas.

La situation est dans l'impasse: tout le monde comprend qu'il y a un problème avec le code, mais ils ne peuvent pas sortir de ce cercle. J'ai suggéré une migration modulaire progressive vers yii2. Après 1,5 mois, une partie du site a commencé à fonctionner sur yii2, ce qui signifie qu'il y a un endroit pour migrer et une infrastructure où vous pouvez travailler de manière significative. Bien sûr, vous pouvez continuer à mal écrire, mais vous ne pouvez plus vous justifier avec le «regard sur ce qu'est l'horreur».

Réfléchissez avant de commencer

Pour ma part, j'ai identifié plusieurs règles. Si vous lancez une migration, alors soit ils doivent être respectés, soit vous ne devez pas la démarrer.

1. Il est nécessaire de comprendre et d'accepter «pourquoi avons-nous besoin d'hémorroïdes». Il peut y avoir n'importe quelle motivation, mais elle devrait l'emporter sur tous les inconvénients avec une grande marge.
2. Vous ne devez pas démarrer la migration si le projet n'a pas d'avenir clair dans les prévisions 2 à 3 ans à l'avance. Ou vous le faites pour le plaisir.
3. Nous écrivons toutes les nouvelles fonctionnalités, tous les développements, tous les nouveaux sur yii2. En yii1, seul le support devrait rester. Si cette règle n'est pas respectée, vous recevrez immédiatement 2 branches actives, ce qui nécessitera 2 fois plus de ressources. Et, comme il n'y a toujours pas assez de ressources, tout cela peut s'arrêter.
4. Ne définissez pas la tâche «réécrire bêtement tout ce qui est». «Tout réécrire» est si abstrait et ennuyeux que si vous le dites à votre équipe dans ce libellé, vous pouvez lire beaucoup de choses intéressantes à leur sujet dans leurs visages tristes.
5. Parce que même si «tout ce que vous voulez» ne peut pas être réécrit immédiatement, alors vous avez besoin d'un plan de migration progressive - par pages, par services, par modules.
6. La chose la plus importante! Il est préférable de considérer la migration vers yii2 comme une refonte profonde de l'ensemble du projet visant au développement. Ensuite, il peut s'avérer qu'un tiers du projet n'a pas du tout besoin d'être réécrit (s'il fonctionne bien "tel quel" et ne nécessite qu'un soutien minimal), et qu'une partie du projet peut être magnifiquement enterrée. C'est-à-dire non seulement de tuer des services / pages, mais aussi de refaire le projet afin qu'ils ne soient tout simplement pas nécessaires.

Idée de migration

Mon idée de migration est la collaboration simultanée de deux branches d'un même projet sur yii1 et yii2 dans le même domaine, sur le même hôte virtuel. Progressivement, portez étape par étape les services / pages / modules vers yii2.

Par exemple, il existe un site qui fonctionne sur yii1

site.ru/ #  site.ru/news #  site.ru/pages #  site.ru/comments #  

Nous avons copié les nouvelles sur yii2, reçu:

 site.ru/ #  site.ru/news #  (yii2) site.ru/pages #  site.ru/comments #  

Avis réécrits, reçus

 site.ru/ #  site.ru/news #  (yii2) site.ru/pages #  site.ru/comments #  (yii2) 

Et donc progressivement, page par page, jusqu'à ce que nous réécrivions tout ce que nous voulons réécrire. Il est clair que plus nous réécrivons, plus le processus se déroule facilement. Le plus difficile est toujours la première étape: première page, premier module, premier service.

Première partie Juste pour travailler en même temps

J'ajouterai des tautologies, mais tout est vraiment simple. Dans le cas le plus simple, conservez les deux branches (yii1 et yii2) dans le même espace de travail, comme ceci:

 /var/www/site/htdocs/ - DOCUMENT_ROOT   /var/www/site/yii1/ -   yii1 /var/www/site/yii2/ -   yii2 

Peu importe comment nommer et placer des répertoires. Il est nécessaire de s'assurer que le code sur yii1 et yii2 se trouve à proximité et est disponible pour fonctionner dans un hôte virtuel. Et toute la magie du travail simultané sera dans les scripts d'entrée index.php et .htaccess.

Quels sont les avantages de cette approche:

• Dans votre environnement de développement, 2 branches de projet seront disponibles immédiatement. Cela peut être pratique, car pendant longtemps, vous devez travailler avec eux en même temps, en changeant d'avant en arrière.
  
• Les deux projets auront un accès direct à DOCUMENT_ROOT, ce qui est important pour un travail simple avec la statique css / js.

Les inconvénients peuvent être à la fois esthétiques (par type: quel obstacle à interférer tous ensemble), et associés à un travail multi-utilisateurs. Oui, vous pouvez fractionner les emplacements de stockage de code et fractionner les projets dans un environnement de développement. Cela ne change pas l'essence, ajoutez simplement des nuances.

Personnellement, j'ai créé un projet distinct pour la branche yii2 dans l'EDI, même lorsque les fichiers de branche se trouvaient physiquement à proximité.

Exemple de base. Sources des branches de projet yii1 / yii2 dans un répertoire

DOCUMENT_ROOT utilise 2 scripts d'entrée.

 index.php -  yii1 index_yii2.php -  yii2. 

index.php
Si vous ne changez pas la structure de fichiers du projet en yii1, votre index.php restera inchangé.


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
Dans .htaccess, nous ferons le routage entre yii1 et 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 

C'est-à-dire Les URL suivantes sont gérées par index_yii2.php et exécutées sur yii2.

 https://site/test https://site/news https://site/page/one 

Le reste du site est index.php (yii1).

Il s'agit d'un lancement simultané de base. Bien sûr, chacun aura ses propres nuances: une équipe, des utilisateurs, des droits d'accès, des serveurs, différents référentiels, etc. Et chacun aura son propre jardin.

Les codes sources des branches yii1 / yii2 sont distribués dans des répertoires

Par exemple, si vous avez votre propre serveur, vous pouvez publier le stockage des branches de projet dans différents répertoires.

 /var/www/site/htdocs - DOCUMENT_ROOT    site.ru /var/www/site/protected -   yii1 /srv/site_yii2 -   yii2 

Ensuite, vous devez modifier le chemin d'accès au répertoire avec le projet yii2 dans index_yii2.php. Bien sûr, cela fonctionnera s'il est désactivé ou si open_basedir est configuré. Plus les droits correspondants sur le serveur et désactivé / configuré, SELinux.

Et ensuite

S'il y a des utilisateurs sur le site, alors l'autorisation unique est un élément critique sans lequel le fonctionnement simultané de 2 succursales est, en fait, impossible. Dans le prochain article, j'ai l'intention de montrer à quel point il est facile d'organiser une seule autorisation. Par exemple, l'autorisation elle-même reste dans yii1, mais les utilisateurs autorisés sont visibles de manière transparente dans la branche yii2 ou vice versa.