Migrando um projeto do yii1 para o yii2 por meio de um trabalho único



“Algumas vezes” tive que lidar com a migração de projetos do yii1 para o yii2 e quero compartilhar minha experiência com a comunidade. Não há nada complicado neste processo e não haverá revelações. A natureza da publicação é sua experiência + tutorial para iniciantes.

Antecedentes


Se os projetos historicamente criados na primeira versão do yii continuarem evoluindo, todo desenvolvedor que trabalha com eles mais cedo ou mais tarde terá a seguinte idéia: “ quão bom seria se estivesse no yii2 ”.

Mas as coisas geralmente não vão além dos pensamentos, porque a quantidade de trabalho parece colossal. De um modo geral, o volume é enorme, mas ainda não é proibitivo - de acordo com o provérbio "os olhos têm medo". Além disso, para a transição para a ação, é necessária uma certa força de vontade (eu, internamente, estou me preparando para a migração do primeiro projeto há quase um ano).

Minha idéia de migração está sob o gato.

Antes de "mostrar o código", escreverei muitas letras "por que fiz isso", porque razões determinam a natureza do trabalho. Eu tive 2 casos semelhantes.

No primeiro projeto, tudo foi simples. Sou co-proprietário e o único desenvolvedor. Portanto, a razão "estou cansado de escrever no yii1" é bastante convincente. A escrita deve ser "alta", caso contrário, o resultado pode ser uma porcaria de má qualidade.

No segundo caso, sou contratado em um projeto que foi escrito por vários desenvolvedores por um longo tempo sem uma arquitetura clara. Portanto, a saída foi um monte de códigos herdados. Reescrever dessa maneira é mais fácil desistir; o cliente não reconhece a refatoração por uma questão de refatoração; portanto, cada novo desenvolvedor aumentou ainda mais a pilha.

A situação é impassível: todo mundo entende que há um problema com o código, mas não pode sair deste círculo. Sugeri migração modular gradual para yii2. Após 1,5 meses, parte do site começou a trabalhar no yii2, o que significa que há um lugar para migrar e uma infraestrutura na qual você pode trabalhar de maneira significativa. Obviamente, você pode continuar a escrever mal, mas não pode mais se justificar com o "olhar para o que há de horror".

Pense antes de começar


Para mim, identifiquei várias regras. Se você iniciar uma migração, eles devem ser respeitados ou você não deve iniciá-la.

  1. É necessário entender e aceitar "por que precisamos de hemorróidas". Pode haver alguma motivação, mas deve superar todas as desvantagens com uma grande margem.
  2. Você não deve iniciar a migração se o projeto não tiver um futuro claro na previsão por 2-3 anos de antecedência. Ou você faz isso por diversão.
  3. Nós escrevemos todas as novas funcionalidades, todo desenvolvimento, tudo novo no yii2. No yii1, apenas o suporte deve permanecer. Se essa regra não for seguida, você receberá imediatamente 2 ramificações ativas, o que exigirá 2 vezes mais recursos. E, como nem sempre há recursos suficientes, tudo isso pode terminar.
  4. Não defina a tarefa "reescrever estupidamente tudo o que é". “Reescrever tudo” é tão abstrato e chato que, se você expressar isso para sua equipe com essas palavras, poderá ler muitas coisas interessantes sobre eles em seus rostos tristes.
  5. Porque mesmo que "tudo o que você deseja" não possa ser reescrito imediatamente, você precisará de um plano para migração gradual - por páginas, serviços, módulos.
  6. A coisa mais importante! É melhor considerar a migração para o yii2 como uma refatoração profunda de todo o projeto destinado ao desenvolvimento. Então, pode acontecer que um terço do projeto não precise ser reescrito (se funcionar bem "como está" e exigir apenas o mínimo de suporte), e parte do projeto poderá ser maravilhosamente enterrada. I.e. não apenas matando serviços / páginas, mas também refazendo o projeto para que eles simplesmente não sejam necessários.

Ideia de migração


Minha ideia de migração é a colaboração simultânea de duas ramificações do mesmo projeto no yii1 e yii2 no mesmo domínio, no mesmo host virtual. Gradualmente, passo a passo porta serviços / páginas / módulos para yii2.

Por exemplo, existe um site que é executado no yii1

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

Copiamos as notícias no yii2, recebemos:

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

Revisões reescritas, recebidas

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

E gradualmente, página por página, até reescrever tudo o que queremos reescrever. É claro que, quanto mais reescrevemos, mais fácil o processo. O mais difícil é sempre o primeiro passo: primeira página, primeiro módulo, primeiro serviço.

Parte I Apenas para trabalhar ao mesmo tempo


Vou adicionar tautologias, mas tudo é realmente simples. No caso mais simples, mantenha os dois ramos (yii1 e yii2) no mesmo espaço de trabalho, assim:

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

Mais ou menos
 /var/www/site/public_html/ - DOCUMENT_ROOT   /var/www/site/protected/ -   yii1 /var/www/site/yii2/ -   yii2 

mais ou menos
 /var/www/site/ - DOCUMENT_ROOT   /var/www/site/protected/ -   yii1 /var/www/site/yii2/ -   yii2 


Não importa como nomear e colocar diretórios. É necessário garantir que o código em yii1 e yii2 esteja próximo e esteja disponível para trabalhar em um host virtual. E toda a magia do trabalho simultâneo estará nos scripts de entrada index.php e .htaccess.

Quais são as vantagens dessa abordagem:


  • No seu ambiente de desenvolvimento, duas ramificações do projeto estarão disponíveis imediatamente. Pode ser conveniente, porque por um longo tempo, você precisa trabalhar com eles ao mesmo tempo, alternando entre si.
  • Ambos os projetos terão acesso direto ao DOCUMENT_ROOT, o que é importante para o trabalho simples com estática css / js.

Os contras podem ser estéticos (por tipo: que obstáculo pode interferir todos juntos) e associados ao trabalho multiusuário. Sim, você pode dividir os locais de armazenamento de código e os projetos em um ambiente de desenvolvimento. Isso não muda a essência, basta adicionar nuances.

Pessoalmente, criei um projeto separado para a ramificação yii2 no IDE, mesmo quando os arquivos das ramificações estavam fisicamente próximos.

Exemplo básico. Fontes das ramificações do projeto yii1 / yii2 em um diretório


DOCUMENT_ROOT usa 2 scripts de entrada.

 index.php -  yii1 index_yii2.php -  yii2. 

Na estrutura do arquivo
 htdocs/ htdocs/index.php htdocs/index_yii2.php yii1/ yii2/ 


index.php
Se você não alterar a estrutura do arquivo do projeto para yii1, seu index.php permanecerá inalterado.

Por exemplo
 <?php /* * -     . *   , ..     yii1 index.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'); //     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
No .htaccess, faremos o roteamento entre yii1 e 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 

I.e. Os seguintes URLs são tratados pelo index_yii2.php e executados no yii2.

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

O restante do site é index.php (yii1).

Este é um lançamento simultâneo básico. Obviamente, cada um terá suas próprias nuances: uma equipe, usuários, direitos de acesso, servidores, diferentes repositórios, etc. E todo mundo terá seu próprio jardim.

Os códigos-fonte das ramificações yii1 / yii2 são distribuídos em diretórios


Por exemplo, se você tiver seu próprio servidor, poderá postar o armazenamento de ramificações do projeto em diretórios diferentes.

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

Então você precisa alterar o caminho para o diretório com o projeto yii2 em index_yii2.php. Obviamente, isso funcionará se estiver desabilitado ou se o open_basedir estiver configurado. Além dos direitos correspondentes no servidor e desativado / 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();?> 



O que vem a seguir


Se houver usuários no site, a autorização única é um elemento crítico sem o qual a operação simultânea de 2 ramificações é, de fato, impossível. No próximo artigo, pretendo mostrar como é fácil organizar uma única autorização. Por exemplo, a autorização em si permanece no yii1, mas os usuários autorizados são visíveis de forma transparente na ramificação do yii2 ou vice-versa.

Source: https://habr.com/ru/post/pt417677/


All Articles