Patch ou Core Hack

Quando estou em um projeto de atualização do sistema, uma das coisas que faço é diferenciar o sistema de um cliente em uma nova instalação do Magento. Estou procurando por hacks principais ou arquivos adicionais que não fazem parte do Magento padrão, para garantir que eu receba qualquer trabalho crítico, mas de negócios, realizado por um freelancer, contratado, consultor ou agência anterior.

Uma coisa que sempre me surpreende são os remendos. Ao longo dos anos, o Magento emitiu patches "entre versões" - geralmente para corrigir uma correção de segurança ou uma alteração na API do fornecedor de remessa / pagamento.

O problema é que, do ponto de vista de um diff, os patches são indistinguíveis dos hacks principais - especialmente quando você não sabe quais patches (se houver) foram aplicados ao sistema.

O que leva à minha pergunta.

Como você diferencia entre um hack principal e um patch?

Os patches Magento fornecidos pelo suporte anexarão um tipo de log a app/etc/applied.patches.list. Não sei quando ou há quanto tempo os "scripts" do patch estão fazendo isso. Os patches da CE também parecem fazer isso.

Isso é algo com que eu lido frequentemente (e estou trabalhando agora) e, infelizmente, até agora é um processo totalmente manual - temos um processo automatizado que sinaliza todos os arquivos que podem ser modificados como parte de nossa auditoria automatizada inicial para um novo cliente de suporte. Em seguida, temos alguém que difere esses arquivos e exclui quaisquer falsos positivos óbvios (ou seja, alterações de espaço em branco).

Então, a parte divertida - um membro sênior da nossa equipe que trabalha com o Magento há algum tempo precisa dar uma olhada nos resultados para determinar se algum dos arquivos modificados pode ser o resultado de um patch. Examinamos a atualização do nosso sistema para verificar se há todos os patches que conhecemos / que podem funcionar, e que podem funcionar para o CE, mas no EE é ainda mais desafiador, pois o suporte ao EE às vezes emite patches diretamente para clientes que nunca são liberados de outra maneira ou catalogados de maneira consistente.

Portanto, quando fazemos esse nível de revisão, contamos com a experiência passada na aplicação desses patches + senso comum (ou seja, é apenas uma alteração no ponto de extremidade de uma API? Em caso afirmativo, esse ponto de extremidade alterado está presente na versão atualizada? era um patch e pode ser ignorado).

Teoricamente, seria simples aplicar todos os patches disponíveis na página de download do CE etc. a todas as versões aplicáveis ​​do CE e compará-los (FYI, não usamos diff para o primeiro passe - usamos hash, em parte porque incorporamos essa tecnologia em uma ferramenta que pode verificar remotamente em um site sem precisar fazer o download primeiro). Isso excluiria a maioria dos patches, mas ainda não ajuda em nenhum patch CE ou EE que não seja publicado na área de download pública do CE ou na área de download protegida / cliente do EE. Isso exigiria que o Magento estabelecesse uma política consistente de que TODOS os patches fossem disponibilizados para TODOS os clientes e os publicasse onde pudéssemos chegar a eles.

Então, acho que não há uma maneira de automatizar 100% disso até que as mudanças aconteçam no lado Magento, infelizmente.

Uma maneira de abordar isso quando eu estava fazendo muitas atualizações e tentando sistematizar o processo era realmente confirmar os patches diretamente no seu repositório de código principal que você está usando para diferenciar.

Na verdade, isso tem dois benefícios:

1. Não há mais falsos positivos aparecendo em suas diferenças.

2. Digamos que você tenha um site que não possui um determinado patch. Você pode dizer que é um problema, porque ele aparecerá como código ausente no seu diff, embora tecnicamente eles não estejam faltando nada em comparação com um novo download sem patch. Mas, na verdade, a falta de um patch é realmente um problema que deve ser resolvido - por isso, é perfeito que apareça no seu diff para você consertar a atualização.

Não acho que ter um Magento no repo do projeto seja uma boa ideia inicialmente, caso você gerencie mais de 2 a 3 clientes. Como é sempre mais fácil atrapalhar as correções do sistema aplicadas com os principais hacks.

A melhor opção, na minha opinião, é ter um espelho de repositório Magento do compositor com tags de versão, que aponte para uma versão específica do Magento com possíveis patches oficiais aplicados.

Além disso, seria mais fácil manter suas próprias correções nos arquivos, como Mage_Core_Model_Config para sites de alta carga e outros, introduzindo sua parcela via compositor com um número de versão que corresponda à sua parcela do Magento.

Portanto, nesse caso, sua atualização de todos os projetos do cliente para um código Magento corrigido resultará apenas na versão do seu arquivo de composição. Manter o código do projeto separado do núcleo forçará seus desenvolvedores a não invadir o núcleo.

Quanto à definição de patch e hack, eu preferiria chamá-lo assim:

1. Uma mudança no arquivo principal original pelo arquivo de patch oficial - é um patch
2. Uma alteração no arquivo principal original da sua equipe - é um hack.
3. Uma alteração no arquivo principal copiado local para fins de correção de erros - é um patch
4. Uma alteração no arquivo principal copiado local para fornecer novas funcionalidades - é um hack

Portanto, movendo o core para um repositório separado, você terá a certeza de ter apenas a versão corrigida de acordo com o item 1. E você pode instalar facilmente seus próprios patches sobre o compositor no pool de códigos local, para ter tudo de acordo com o ponto 3. No caso de 2 e 4, você pode criar um gancho de confirmação do git no repositório de projetos para proibir qualquer confirmação de código nesse diretório.

Eu olho para o arquivo de patches aplicados nessa /app/etc/pasta e trabalho para trás. Mas, como aprendi com a atualização, posso excluir o arquivo em uma versão que contém o arquivo corrigido e, da próxima vez, é limpo.

Qualquer coisa do Magento eu chamaria de patch. Tudo o resto é um hack.