Patch ou Core Hack

14

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?

Alan Storm
fonte

Respostas:

16

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.

beeplogic
fonte
Arrumado! Eu não sabia disso. Você sabe se isso faz parte do .patch real - ou o suporte o faz manualmente? Ou (provavelmente?) Ambos? Observando alguns arquivos .patch antigos e não vendo nenhuma alteração em um arquivo Aplicado.patches.list.
Alan Storm
Auto ajudou a que essa última - os patches CE que este automatizada (ver: magentocommerce.com/index.php/getmagento/ce_patches/... )
Alan Storm
2
Parece (e @ joshua-s-warren parece confirmar) que nem todos os arquivos de patch são criados iguais. Se tivermos "sorte", o patch terá essa funcionalidade incorporada. Aqui está um exemplo de um que possui: magentocommerce.com/index.php/getmagento/ce_patches/… Também lista apenas os arquivos que foram alterados e não as alterações você teria que tentar rastrear o patch para saber o que mudou, mesmo assim não há "garantia" de que foi o mesmo usado.
beeplogic
2
Infelizmente a maioria das manchas EE que temos, não tem essa funcionalidade
Allan MacGregor
4
Todos os patches distribuídos como arquivos .sh para tickets SUPEE devem ter essa funcionalidade (a menos que antigos). Surpreendido @AllanMacGregor você não vê. Você tem um exemplo de um patch que foi aplicado (número SUPEE), mas não listado?
Piotr Kaminski
7

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.

Joshua S Warren
fonte
2
Com o repositório github das versões magento, é trivial deixar o git fazer o trabalho. Nenhum hash personalizado é necessário. Basta adicionar remoto, buscar remoto e git diff depot/master origin/master. O desafio é o .gitignore. Outra opção é clonar a versão em um diretório separado e copiar o app/code/corediretório dos sites sobre ele. git diff -wentão lhe dirá.
22414 Melvyn
Fizemos dessa maneira porque geralmente testamos isso remotamente em servidores que não permitem a instalação de software e podem não ter o git instalado. Porém, em um ambiente em que o git está presente, você está certo, pode usar o git diff.
Joshua S Warren
Ah sim, entendo o seu ponto. Na verdade, vou pensar em como colocar algo assim no magerun.
Melvyn
4

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.

kalenjordan
fonte
4

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.

Ivan Chepurnyi
fonte
3

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.

jeremy.bass
fonte
2

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

Josh Pennington
fonte
1
Concordo, mas é como saber qual é qual após o fato.
Alan Storm
Eu provavelmente faria uma comparação da sua comparação na instalação base e, em seguida, uma comparação adicional contra uma instalação com cada patch aplicado separadamente (ou apenas o resultado final de todos os patches aplicados). Provavelmente será um pouco mais de magnitude de trabalho, mas é a única maneira que consigo pensar.
Josh Pennington