“Un par de veces” tuve que lidiar con la migración de proyectos de yii1 a yii2 y quiero compartir mi experiencia con la comunidad. No hay nada complicado en este proceso y no habrá revelaciones. La naturaleza de la publicación es su experiencia + tutorial para principiantes.
Antecedentes
Si los proyectos realizados históricamente en la primera versión de yii continúan evolucionando, cada desarrollador que trabaje con ellos tarde o temprano tiene la idea: "
qué bueno sería si estuviera en yii2 ".
Pero las cosas generalmente no van más allá de los pensamientos, porque La cantidad de trabajo parece colosal. En general, tal como es, el volumen es enorme, pero aún no es prohibitivo, según el proverbio "los ojos tienen miedo". Además, para la transición a la acción, se necesita cierta fuerza de voluntad (internamente, me he estado preparando para la migración del primer proyecto durante casi un año).
Mi idea de migración está bajo cat.
Antes de "mostrar el código" escribiré muchas letras "por qué hice esto", porque razones determinan la naturaleza del trabajo. Tuve 2 casos similares.
En el primer proyecto, todo fue simple. Soy copropietario y el único desarrollador. Por lo tanto, la razón "Estoy cansado de escribir en yii1" es bastante convincente. La escritura debe ser "alta", de lo contrario el resultado puede ser una
basura de mala calidad.
En el segundo caso, soy un contratista en un proyecto que ha sido escrito por varios desarrolladores durante mucho tiempo sin una arquitectura clara. Por lo tanto, la salida fue un enorme montón de código heredado. Reescribir de esta manera es más fácil de
disparar, dejando de fumar; el cliente no reconoce la refactorización por el bien de la refactorización, por lo que cada nuevo desarrollador ha aumentado aún más el montón.
La situación está estancada: todos entienden que hay un problema con el código, pero no pueden salir de este círculo. Sugerí la migración modular gradual a yii2. Después de 1,5 meses, parte del sitio comenzó a funcionar en yii2, lo que significa que hay un lugar para migrar y una infraestructura donde puede trabajar de manera significativa. Por supuesto, puedes seguir escribiendo mal, pero ya no puedes justificarte con el "mira qué horror hay".
Piensa antes de comenzar
Para mí, he identificado varias reglas. Si inicia una migración, debe respetarlas o no debe iniciarla.
- Es necesario comprender y aceptar "por qué necesitamos hemorroides". Puede haber alguna motivación, pero debería superar todas las desventajas con un amplio margen.
- No debe comenzar la migración si el proyecto no tiene un futuro claro en el pronóstico con 2-3 años de anticipación. O lo haces por diversión.
- Escribimos todas las nuevas funcionalidades, todo el desarrollo, todo nuevo en yii2. En yii1, solo debe permanecer el soporte. Si no se sigue esta regla, recibirá inmediatamente 2 ramas activas, lo que requerirá 2 veces más recursos. Y, dado que siempre no hay suficientes recursos, todo esto puede terminar.
- No establezca la tarea "reescribe estúpidamente todo lo que es". "Reescribir todo" es tan abstracto y aburrido que si se lo dices a tu equipo con esta redacción, en sus caras tristes puedes leer muchas cosas interesantes sobre ti.
- Porque incluso si "todo lo que desea" no puede reescribirse de inmediato, entonces necesita un plan para la migración gradual: por páginas, por servicios, por módulos.
- Lo mas importante! Es mejor considerar la migración a yii2 como una refactorización profunda de todo el proyecto dirigido al desarrollo. Entonces puede resultar que un tercio del proyecto no necesita ser reescrito en absoluto (si funciona bien "como está" y requiere un apoyo mínimo), y parte del proyecto puede quedar bellamente enterrado. Es decir no solo matando servicios / páginas, sino también rehaciendo el proyecto para que simplemente no sean necesarios.
Idea de la migración
Mi idea de migración es la colaboración simultánea de dos ramas del mismo proyecto en yii1 y yii2 en el mismo dominio, en el mismo host virtual. Poco a poco, paso a paso servicios de puerto / páginas / módulos a yii2.
Por ejemplo, hay un sitio que se ejecuta en yii1
site.ru/ # site.ru/news # site.ru/pages # site.ru/comments #
Copiamos las noticias en yii2, recibimos:
site.ru/ # site.ru/news # (yii2) site.ru/pages # site.ru/comments #
Revisiones reescritas, recibidas
site.ru/ # site.ru/news # (yii2) site.ru/pages # site.ru/comments # (yii2)
Y así gradualmente, página por página, hasta que reescribamos todo lo que queremos reescribir. Está claro que cuanto más reescribimos, más fácil será el proceso. Lo más difícil es siempre el primer paso: primera página, primer módulo, primer servicio.
Primera parte Solo para trabajar al mismo tiempo
Agregaré tautologías, pero todo es realmente simple. En el caso más simple, mantenga ambas ramas (yii1 y yii2) en el mismo espacio de trabajo, así:
/var/www/site/htdocs/ - DOCUMENT_ROOT /var/www/site/yii1/ - yii1 /var/www/site/yii2/ - yii2
O eso /var/www/site/public_html/ - DOCUMENT_ROOT /var/www/site/protected/ - yii1 /var/www/site/yii2/ - yii2
mas o menos
/var/www/site/ - DOCUMENT_ROOT /var/www/site/protected/ - yii1 /var/www/site/yii2/ - yii2
No importa cómo nombrar y colocar directorios. Es necesario asegurarse de que el código en yii1 y yii2 se encuentre cerca y esté disponible para trabajar en un host virtual. Y toda la magia del trabajo simultáneo estará en los scripts de entrada index.php y .htaccess.
¿Cuáles son las ventajas de este enfoque?
- En su entorno de desarrollo, 2 ramas de proyectos estarán disponibles de inmediato. Puede ser conveniente porque durante mucho tiempo tienes que trabajar con ellos al mismo tiempo, cambiando de un lado a otro.
- Ambos proyectos tendrán acceso directo a DOCUMENT_ROOT, que es importante para un trabajo simple con estadísticas css / js.
Los contras pueden ser tanto estéticos (por tipo: qué obstáculo interferir todos juntos) como asociados con el trabajo multiusuario. Sí, puede dividir ubicaciones de almacenamiento de código y proyectos divididos en un entorno de desarrollo. Esto no cambia la esencia, solo agrega matices.
Personalmente, creé un proyecto separado para la rama yii2 en el IDE, incluso cuando los archivos de la rama estaban físicamente cerca.
Ejemplo básico. Fuentes de las ramas del proyecto yii1 / yii2 en un directorio
DOCUMENT_ROOT usa 2 scripts de entrada.
index.php - yii1 index_yii2.php - yii2.
En estructura de archivo htdocs/ htdocs/index.php htdocs/index_yii2.php yii1/ yii2/
index.phpSi no cambia la estructura de archivos para el proyecto a yii1, su index.php permanecerá sin cambios.
Por ejemplo <?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');
.htaccessEn .htaccess haremos un enrutamiento entre yii1 y 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
Es decir Las siguientes URL son manejadas por index_yii2.php y se ejecutan en yii2.
https://site/test https://site/news https://site/page/one
El resto del sitio es index.php (yii1).
Este es un lanzamiento concurrente básico. Por supuesto, cada uno tendrá sus propios matices: un equipo, usuarios, derechos de acceso, servidores, diferentes repositorios, etc. Y cada uno tendrá su propio jardín.
Los códigos fuente de las ramas yii1 / yii2 se distribuyen en directorios
Por ejemplo, si tiene su propio servidor, puede publicar el almacenamiento de ramas de proyectos en diferentes directorios.
/var/www/site/htdocs - DOCUMENT_ROOT site.ru /var/www/site/protected - yii1 /srv/site_yii2 - yii2
Luego debe cambiar la ruta al directorio con el proyecto yii2 en index_yii2.php. Por supuesto, esto funcionará si está deshabilitado o si open_basedir está configurado. Además de los derechos correspondientes en el servidor y deshabilitado / configurado, 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();?>
Que sigue
Si hay usuarios en el sitio, entonces la autorización única es un elemento crítico sin el cual la operación simultánea de 2 sucursales es, de hecho, imposible. En el próximo artículo, planeo mostrar lo fácil que es organizar una única autorización. Por ejemplo, la autorización en sí permanece en yii1, pero los usuarios autorizados son visibles de forma transparente en la rama yii2 o viceversa.