Migrieren eines Projekts von yii1 nach yii2 durch einen einmaligen Job

„Ein paar Mal“ musste ich mich mit der Migration von Projekten von yii1 nach yii2 befassen und möchte meine Erfahrungen mit der Community teilen. Es gibt nichts Kompliziertes in diesem Prozess und es wird keine Offenbarungen geben. Die Art der Veröffentlichung ist Ihre Erfahrung + Tutorial für Anfänger.

Hintergrund

Wenn sich die Projekte, die historisch auf der ersten Version von yii erstellt wurden, weiterentwickeln, kommt jeder Entwickler, der früher oder später mit ihnen arbeitet, auf den Gedanken: „ Wie gut wäre es, wenn es auf yii2 wäre “.

Aber die Dinge gehen normalerweise nicht über die Gedanken hinaus, weil Der Arbeitsaufwand scheint kolossal. So wie es ist, ist die Lautstärke im Allgemeinen riesig, aber immer noch nicht unerschwinglich - laut dem Sprichwort „Augen haben Angst“. Außerdem ist für den Übergang zum Handeln eine gewisse Willenskraft erforderlich (ich bereite mich intern seit fast einem Jahr auf die Migration des ersten Projekts vor).

Meine Vorstellung von Migration ist unter Katze.

Bevor ich den Code zeige, schreibe ich viele Buchstaben: "Warum habe ich das getan?" Gründe bestimmen die Art der Arbeit. Ich hatte 2 ähnliche Fälle.

Im ersten Projekt war alles einfach. Ich bin sowohl Miteigentümer als auch der einzige Entwickler. Daher ist der Grund "Ich bin es einfach leid, in yii1 zu schreiben" ziemlich überzeugend. Das Schreiben sollte "hoch" sein, sonst kann das Ergebnis ein Mist von schlechter Qualität sein.

Im zweiten Fall bin ich Auftragnehmer in einem Projekt, das lange Zeit von verschiedenen Entwicklern ohne klare Architektur geschrieben wurde. Daher war die Ausgabe eine riesige Menge an Legacy-Code. Das Umschreiben auf diese Weise ist einfacher, wenn Sie das Beenden beenden. Der Kunde erkennt das Refactoring aus Gründen des Refactorings nicht an, sodass jeder neue Entwickler den Heap noch weiter vergrößert hat.

Die Situation ist Patt: Jeder versteht, dass es ein Problem mit dem Code gibt, aber er kann nicht aus diesem Kreis ausbrechen. Ich schlug eine schrittweise modulare Migration zu yii2 vor. Nach 1,5 Monaten begann ein Teil der Site mit der Arbeit an yii2, was bedeutet, dass es einen Ort für die Migration und eine Infrastruktur gibt, in der Sie sinnvoll arbeiten können. Natürlich können Sie weiterhin schlecht schreiben, aber Sie können sich nicht länger mit dem „Blick darauf, was für ein Horror es gibt“ rechtfertigen.

Denken Sie nach, bevor Sie anfangen

Für mich selbst habe ich mehrere Regeln identifiziert. Wenn Sie eine Migration starten, müssen diese entweder beachtet werden oder Sie sollten sie nicht starten.

1. Es ist notwendig zu verstehen und zu akzeptieren, "warum wir Hämorrhoiden brauchen". Es kann jede Motivation geben, aber sie sollte alle Nachteile mit einem großen Spielraum überwiegen.
2. Sie sollten die Migration nicht starten, wenn das Projekt 2-3 Jahre im Voraus keine klare Zukunft in der Prognose hat. Oder du machst es zum Spaß.
3. Wir schreiben alle neuen Funktionen, alle Entwicklungen, alle neuen auf yii2. In yii1 sollte nur noch Unterstützung übrig sein. Wenn diese Regel nicht befolgt wird, erhalten Sie sofort 2 aktive Zweige, für die zweimal mehr Ressourcen erforderlich sind. Und da es immer nicht genügend Ressourcen gibt, kann dies alles enden.
4. Stellen Sie die Aufgabe nicht "dumm alles neu schreiben, was ist". "Alles neu schreiben" ist so abstrakt und langweilig, dass Sie, wenn Sie es Ihrem Team in dieser Formulierung sagen, in ihren traurigen Gesichtern viele interessante Dinge über sich selbst lesen können.
5. Weil Auch wenn „alles, was Sie wollen“ nicht sofort neu geschrieben werden kann, benötigen Sie einen Plan für die schrittweise Migration - nach Seiten, nach Diensten, nach Modulen.
6. Das wichtigste! Es ist am besten, die Migration zu yii2 als tiefgreifendes Refactoring des gesamten auf Entwicklung ausgerichteten Projekts zu betrachten. Dann kann sich herausstellen, dass ein Drittel des Projekts überhaupt nicht neu geschrieben werden muss (wenn es "wie es ist" gut funktioniert und nur minimale Unterstützung erfordert) und ein Teil des Projekts wunderschön vergraben werden kann. Das heißt, nicht nur Dienste / Seiten zu töten, sondern auch das Projekt zu wiederholen, damit sie einfach nicht benötigt werden.

Idee der Migration

Meine Idee der Migration ist die gleichzeitige Zusammenarbeit von zwei Zweigen desselben Projekts auf yii1 und yii2 in derselben Domäne auf demselben virtuellen Host. Schritt für Schritt Port Services / Seiten / Module nach yii2 portieren.

Zum Beispiel gibt es eine Site, die auf yii1 ausgeführt wird

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

Wir haben die Nachrichten auf yii2 kopiert und erhalten:

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

Umgeschriebene Bewertungen erhalten

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

Und so schrittweise, Seite für Seite, bis wir alles neu schreiben, was wir umschreiben möchten. Es ist klar, dass der Prozess umso einfacher ist, je mehr wir umgeschrieben haben. Am schwierigsten ist immer der erste Schritt: erste Seite, erstes Modul, erster Service.

Teil Eins Nur um gleichzeitig zu arbeiten

Ich werde Tautologien hinzufügen, aber alles ist wirklich einfach. Behalten Sie im einfachsten Fall beide Zweige (yii1 und yii2) im selben Arbeitsbereich bei:

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

Es spielt keine Rolle, wie Verzeichnisse benannt und platziert werden. Es muss sichergestellt werden, dass der Code auf yii1 und yii2 in der Nähe liegt und für die Arbeit auf einem virtuellen Host verfügbar ist. Und die ganze Magie der gleichzeitigen Arbeit steckt in den Eingabeskripten index.php und .htaccess.

Was sind die Vorteile dieses Ansatzes:

• In Ihrer Entwicklungsumgebung stehen sofort 2 Projektzweige zur Verfügung. Es kann bequem sein, weil lange muss man gleichzeitig mit ihnen arbeiten und hin und her wechseln.
  
• Beide Projekte haben direkten Zugriff auf DOCUMENT_ROOT, was für die einfache Arbeit mit der CSS / JS-Statik wichtig ist.

Nachteile können sowohl ästhetisch (nach Typ: was für ein Hindernis, um alle zusammen zu stören) als auch mit Mehrbenutzerarbeit verbunden sein. Ja, Sie können Codespeicherorte und Projekte in einer Entwicklungsumgebung aufteilen. Dies ändert nichts an der Essenz, sondern fügt nur Nuancen hinzu.

Persönlich habe ich ein separates Projekt für den Zweig yii2 in der IDE erstellt, auch wenn die Zweigdateien physisch in der Nähe lagen.

Grundlegendes Beispiel. Quellen der yii1 / yii2-Projektzweige in einem Verzeichnis

DOCUMENT_ROOT verwendet 2 Eingabeskripte.

 index.php -  yii1 index_yii2.php -  yii2. 

index.php
Wenn Sie die Dateistruktur für das Projekt nicht in yii1 ändern, bleibt Ihre index.php unverändert.


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
In .htaccess werden wir zwischen yii1 und yii2 routen

 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 

Das heißt, Die folgenden URLs werden von index_yii2.php verarbeitet und auf yii2 ausgeführt.

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

Der Rest der Site ist index.php (yii1).

Dies ist ein grundlegender gleichzeitiger Start. Natürlich hat jeder seine eigenen Nuancen: ein Team, Benutzer, Zugriffsrechte, Server, verschiedene Repositorys usw. Und jeder wird seinen eigenen Garten haben.

Die Quellcodes der Zweige yii1 / yii2 sind in Verzeichnissen verteilt

Wenn Sie beispielsweise einen eigenen Server haben, können Sie die Speicherung von Projektzweigen in verschiedenen Verzeichnissen veröffentlichen.

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

Dann müssen Sie den Pfad zum Verzeichnis mit dem Projekt yii2 in index_yii2.php ändern. Dies funktioniert natürlich, wenn es deaktiviert oder open_basedir konfiguriert ist. Plus die entsprechenden Rechte auf dem Server und deaktiviert / konfiguriert, SELinux.

Was weiter

Wenn sich Benutzer auf der Site befinden, ist eine einzelne Autorisierung ein kritisches Element, ohne das der gleichzeitige Betrieb von zwei Zweigen tatsächlich unmöglich ist. Im nächsten Artikel möchte ich zeigen, wie einfach es ist, eine einzelne Autorisierung zu organisieren. Beispielsweise bleibt die Autorisierung selbst in yii1, autorisierte Benutzer sind jedoch im Zweig yii2 transparent sichtbar oder umgekehrt.