Visão global:

Esta pergunta foi feita originalmente e depois encerrada no StackOverflow . Afirmamos na meta que aqui é o lugar certo para esta pergunta.

Esta pergunta é a favor de ajudar muitas pessoas a encontrar a maneira correta de estimar as atualizações do Magento.

A questão:

Estou interessado em saber como você mede o tempo necessário para a atualização do Magento? Acho que muitos de vocês tiveram dificuldade em responder à pergunta do cliente: "Quanto tempo levará para atualizar minha loja Magento?"

Normalmente, o cliente precisa ouvir apenas um número, por exemplo: "Levará X horas e custará Y Bucks".

A principal idéia por trás da pergunta é sobre o lado técnico e o que você verifica como desenvolvedor para fazer seus próprios cálculos para atualizações do Magento.

Criei a próxima lista de verificação, apenas para meus próprios cálculos:

• O núcleo do Magento é tocado?
• O esquema do Magento DB foi tocado?
• Temos dados inconsistentes no banco de dados?
• Quantas extensões personalizadas estão instaladas no conjunto de códigos local e da comunidade?
• A extensão personalizada é compatível com a versão mais recente do Magento?
• O desenvolvedor do tema usou o arquivo local.xml para as diretivas de layout ou apenas copiou os arquivos xml da base / default / layout para o diretório de layout do tema personalizado?
• Temos diretivas de layout / métodos de bloco obsoletos nos arquivos xml de layout?
• Eu desenvolvi esta loja Magento?

Você acha que estou perdendo alguma coisa e, se sim, gostaria de compartilhar comigo e com a comunidade seus pontos adicionais para a lista de verificação?

Estimar a atualização do Magento é um processo de coleta de informações sobre as modificações aplicadas na instalação que você está prestes a fazer, verificando se essas modificações podem causar um problema e avaliando quanto tempo é necessário para contorná-las.

Todas as modificações podem ser literalmente divididas em fora do núcleo e dentro do núcleo .

Modificações fora do núcleo são aquelas que não serão substituídas pela atualização. Essas são extensões de terceiros , arquivos principais colocados no escopo local (app / code / local / Mage) e um tema personalizado .

As modificações no núcleo são aplicadas diretamente nos arquivos principais do Magento (app / code / core), arquivos de localização (app / locale / en_US), modelos principais e algumas coisas como javascripts , bibliotecas externas que raramente são personalizadas, mas precisam ser levadas em consideração .

Modificações fora do núcleo

Extensões de terceiros

Durante as atualizações, extensões de terceiros são a principal fonte de problemas. O que significa que, quanto mais extensões você tiver, mais tempo será necessário para analisá-las.

A primeira coisa a verificar é se a funcionalidade fornecida pela extensão ainda não foi implementada em uma versão do Magento para a qual você está atualizando. Por exemplo, algumas extensões como Yoast_CanonicalUrl, Mxperts_CustomerAddressou Fontis_Wysiwygforam amplamente utilizado em Magento 1.3.xx e mais velhos, mas agora fazem parte do núcleo funcionalidade Magento e não é mais necessário.

É uma boa ideia verificar (pergunte ao seu cliente) se você realmente precisa de todas as extensões que possui. Pode haver algumas extensões instaladas, mas nunca realmente usadas. Portanto, neste ponto, é bom fazer uma espécie de limpeza.

Então, uma coisa importante a verificar é a compatibilidade de cada uma das extensões restantes com uma versão do Magento para a qual você está atualizando. Caso algumas extensões não sejam compatíveis e nenhuma extensão semelhante esteja disponível, você terá a opção difícil de perder alguma funcionalidade ou modificar as extensões existentes para torná-las compatíveis.

Nota: Não modifique a extensão de terceiros diretamente, mas crie uma nova extensão que estenda uma desatualizada e, em seguida, defina uma dependência no XML de inicialização da nova extensão.

Depois de tudo isso, é possível fornecer a análise real de cada uma das extensões restantes. Sempre deve começar com o exame do etc/config.xmlarquivo. Há três coisas a procurar:

• A reescrita de classe não é uma técnica limpa por si só, mas em alguns casos não há outra maneira de contornar. Portanto, se a classe reescrita foi alterada na nova versão do Magento, isso pode ser um problema em potencial.
• É menos provável que as atualizações de layout causem um problema com sua atualização, mas ainda assim, se a extensão estiver referenciando um bloco que foi descontinuado em uma versão mais recente do Magento, você precisará contornar isso.
• As atualizações SQL são uma fonte de problemas altamente subestimada durante as atualizações. O problema ocorre quando uma extensão de terceiros está criando uma chave estrangeira que faz referência a algum campo na tabela Magento padrão. Como resultado, este campo está bloqueado de modificações. E, se o script de instalação nativo tentar atualizar esse campo, ele falhará silenciosamente. Depois disso, todos os scripts de instalação a seguir relacionados a este campo travarão sua atualização.

app / code / local / Mage

Depois de terminar as extensões, é hora de dar uma olhada no seu app/code/local/Magediretório. Aqui você encontrará arquivos principais modificados movidos para um localescopo. Cada um deles certamente custará alguns cabelos grisalhos, porque você nunca sabe (se não foi você quem os colocou lá) o que foi modificado lá e por que motivo. Portanto, você deve comparar cada um deles com uma origem e migrar funcionalidades adicionais para o arquivo correspondente da nova versão.

Tema personalizado

A última modificação fora do núcleo foi o tema personalizado. Pode parecer que não é grande coisa, mas na verdade é uma área cinzenta. O tema base do Magento está sendo modificado de versão para versão e cada tema personalizado deve imitar algumas dessas modificações. Infelizmente, não existe uma bala de prata para determinar o que procurar e o que deve ser migrado. Portanto, esteja preparado para algumas surpresas importantes e pequenos detalhes após a atualização.

Modificações no núcleo

No mundo perfeito, não há nenhum. Mas quando você recebe uma instalação do Magento após ter sido abusada por desenvolvedores de terceiros, que estão oferecendo muito barato, você pode esperar qualquer coisa. Portanto, modificações internas são aquelas que serão substituídas durante o processo de atualização. Na maioria dos casos, isso não produzirá erros, mas, como resultado, você perderá a funcionalidade que foi adicionada de maneira tão brutal.

A única maneira de detectar modificações no núcleo é comparar todos os arquivos da instalação do Magento com arquivos limpos da mesma versão. Eu recomendo fazê-lo com o git. Por quê? Simplesmente porque ele lidará bem com todas as novas linhas e espaços em branco.

Mesmo que sua instalação do Magento não esteja sob o git, você ainda pode copiar seus arquivos em um diretório separado e executar o git init. Em seguida, faça o commit inicial, copie os arquivos Magento “limpos” e execute git status. Você obterá algo como isto:

Agora, dependendo do número de arquivos modificados, você pode executar git diffem cada arquivo ou em todo o lote de uma só vez. Isso fornecerá uma referência abrangente de todas as modificações internas feitas. Se você tem alguma visualização git como o phpStorm, a vida é muito mais fácil para você:

Sugiro que git diff > changes.txtvocê sempre tenha uma lista de modificações à mão.

Tendo a lista de modificações principais, é possível estimar o que deve ser transferido para a nova versão e quanto tempo será necessário para isso.

Agora, gostaria de dar alguns conselhos para uma atualização real. Esse processo está bem documentado, portanto não escreverei quais comandos executar e onde clicar. No entanto, quero enfatizar várias coisas importantes:

• Estamos assumindo que você está atualizando em seu ambiente de desenvolvimento. Executar a atualização no servidor de produção é um suicídio.
• Não permita que eles alterem nada na produção enquanto estiver atualizando. Coloque seu Magento sob controle de versão ou até mesmo arquivos temporários de bloqueio.
• Desative todas as extensões de terceiros, mas observe quais foram desativadas inicialmente, para que você não as ative posteriormente.
• Verifique se há um script de limpeza Magento em execução no servidor. Caso contrário truncar todas as tabelas começando com dataflow_*, log_*, report_*.
• Reverta para o tema padrão no momento da atualização.

Após o script de atualização concluído:

• Referenciando o que changes.txtvocê fez antes de migrar todas as modificações internas que realmente valem a pena migrar.
• Migrar app/code/local/Magemodificações encontradas antes da atualização.
• Um a um, ative extensões de terceiros.
• Coloque de volta seu tema e compare exaustivamente o resultado com o servidor de produção.
• Implante a produção quando estiver satisfeito com o resultado.

Conclusão

Sei que tudo isso parece assustador, mas se você estiver atualizando regularmente, mantendo seu núcleo limpo e instalando extensões apenas de fornecedores em quem realmente confia, e somente se você realmente precisar delas, não enfrentará a maioria das dificuldades descritas neste artigo. Mantenha seu Magento EcoSystem saudável e você será recompensado.

Post Scriptum

Em casos muito complicados, faz sentido começar tudo de novo com uma nova instalação do Magento mais recente e migrar o tema e a funcionalidade da sua loja passo a passo. Definitivamente, isso levará tempo, mas no final você terá um sistema Magento saudável, com total consciência do que está acontecendo.

De um modo geral, o código Core nunca deve ser tocado durante o desenvolvimento. Existem muitos mecanismos no Magento que permitem solucionar qualquer problema, inclusive erros internos. Dito isto, há outras questões a serem observadas também.

1. Os módulos locais ou da comunidade substituem o código principal (pode ser pesquisado na pasta modules <rewrite>e é uma prática recomendada, pois eles realmente devem usar código não invasivo, como eventos)
2. O Magento tenta manter o código compatível com versões anteriores, mas às vezes o código muda significativamente ( pode ser encontrado aqui ), se as alterações incompatíveis com versões anteriores forem muitas, que podem ser adicionadas ao processo.
3. É fácil / possível duplicar o código em um ambiente de desenvolvimento. se for, basta executar a atualização e o teste.
4. A atualização é necessária? Existem recursos na nova versão que o cliente não pode deixar sem? Quaisquer problemas de segurança (muitas vezes o Magento também fornece correções)

No que diz respeito ao modelo, pela experiência anterior, posso dizer que ele mal quebra, a menos que o desenvolvedor tenha enlouquecido com a codificação do modelo (que deve estar em blocos de qualquer maneira).

Aqui estão algumas coisas para manter na mente:

• Verifique se o tema é compatível (verifique se há uma codificação extensa nos arquivos de modelo - às vezes os desenvolvedores juniores fazem isso)
• Verifique como a mídia está sendo armazenada (eles estão usando CDNs etc.)
• Verifique se existem métodos especiais de armazenamento em cache (APC Memcached etc)

Uma maneira de lidar com esse tipo de solicitação do cliente é fazer uma revisão de estimativa.

Isso implica dizer ao cliente que você gastará algum tempo (faturável) olhando para ele e fornecerá a eles um prazo / custo mais preciso para a execução do projeto.

Seguir essa rota beneficia você e o cliente.

O cliente geralmente se sentirá mais confiante em sua estimativa e respeitará suas recomendações, o que, por sua vez, beneficia você, reduzindo o possível estresse.

Revisão de estimativa:

A revisão da estimativa real seria algo como estas:

• Despejar o banco de dados ativo e importá-lo em uma máquina de desenvolvimento
• Copie os arquivos magento da máquina ao vivo para a sua máquina dev
• Verifique se está tudo bem e funcionando
• Tente atualizar e faça alguns testes iniciais para ver o que pode estar quebrando

Esse processo deve levar em média duas horas faturáveis ​​e fornecerá as informações necessárias sobre o sistema em questão.

Fizemos várias atualizações no Magento CE, sendo a pior de 1,3 para 1,7, o que levou quase quatro dias completos. A estimativa inicial foi de 1-2 dias. Eu acho que a atualização do 1.x para o 2.x será uma tarefa igualmente grande e, mesmo que as ferramentas de migração sejam fornecidas pela equipe principal, pode ser mais limpo começar do zero.

Quero acrescentar uma coisa às excelentes respostas fornecidas acima:

• Verifique se um VCS e um processo de implantação adequado estão em vigor.

Não farei uma atualização sem os processos adequados por trás dela e a possibilidade de voltar atrás quando ocorrerem problemas (ainda mais se eu não tivesse trabalhado no site antes). Cerca de 90% dos clientes que se aproximam de nós para uma atualização do Magento (que não eram nossos clientes antes) só têm um ambiente ativo sem nenhum teste / teste, VCS em qualquer lugar.

A integração com outras entidades é uma coisa importante a se perguntar. Isso é algo que você talvez não consiga identificar ao olhar para o site - é comum que os clientes tenham sistemas de back-end buscando pedidos por meio da API Magento, por exemplo, e se você não lidar com a continuidade dessa integração enquanto estiver atualizando você pode entrar em uma bagunça.

Ao revisar componentes, procure aqueles que conversam com outros sistemas - cada um deles será complicado de testar porque você não deseja enviar acidentalmente dados de teste para um sistema ativo. Muitas vezes, existe um ponto de extremidade de teste usado pelos desenvolvedores originais, mas você pode não ter mais essas informações ao atualizar.