Patch ou Core Hack

Lorsque je suis sur un projet de mise à niveau du système, l'une des choses que je fais est de différencier le système d'un client contre une nouvelle installation de Magento. Je cherche des hacks de base ou des fichiers supplémentaires qui ne font pas partie de Magento standard pour m'assurer que j'attrape tout travail critique mais commercial effectué par un pigiste, un entrepreneur, un consultant ou une agence précédent.

Une chose qui me bloque toujours, c'est les patchs. Au fil des ans, Magento a publié des correctifs "entre versions" - généralement pour résoudre un problème de sécurité ou un changement dans l'API d'un fournisseur d'expédition / paiement.

Le problème est que, du point de vue d'un diff, les correctifs sont indiscernables des hacks principaux - en particulier lorsque vous ne savez pas quels correctifs (le cas échéant) ont été appliqués au système.

Ce qui m'amène à ma question.

Comment différenciez-vous un hack de base et un patch?

Les correctifs Magento fournis par le support ajouteront un journal de sortes à app/etc/applied.patches.list. Je ne sais pas quand ni depuis combien de temps les "scripts" du patch font ça. Les correctifs CE semblent également faire cela.

C'est quelque chose que je traite souvent (et je travaille en ce moment), et malheureusement, jusqu'à présent, c'est un processus entièrement manuel - nous avons un processus automatisé qui marque chaque fichier qui pourrait être modifié dans le cadre de notre audit automatisé initial pour un nouveau client de support. Nous avons ensuite quelqu'un qui diffère ces fichiers et exclut tout faux positif évident (c'est-à-dire les changements d'espaces).

Ensuite, la partie amusante - un membre senior de notre équipe qui travaille avec Magento depuis un certain temps doit examiner les résultats pour déterminer si l'un des fichiers modifiés pourrait être le résultat d'un correctif. Nous avons envisagé de mettre à jour notre système pour vérifier tous les correctifs que nous connaissons / pouvons obtenir, et cela pourrait fonctionner pour CE, mais sur EE, c'est encore plus difficile, car le support EE délivre parfois des correctifs directement aux clients qui ne sont jamais libérés d'une autre manière ou catalogués de manière cohérente.

Ainsi, lorsque nous effectuons ce niveau d'examen, nous nous appuyons sur l'expérience passée dans l'application de ces correctifs + le bon sens (c'est-à-dire, s'agit-il simplement d'une modification du point de terminaison d'une API? Si oui, ce point de terminaison modifié est-il présent dans la version mise à jour? Si oui, c'était un patch et peut être ignoré).

Il serait théoriquement simple d'appliquer tous les correctifs disponibles sur la page de téléchargement CE, etc., à toutes les versions applicables de CE et de les comparer (pour info, nous n'utilisons pas diff pour la première passe - nous utilisons le hachage, dans partie parce que nous avons intégré cette technologie dans un outil qui peut vérifier à distance sur un site sans avoir besoin de le télécharger au préalable). Cela exclurait la majorité des correctifs, mais cela n'aide toujours pas pour les correctifs CE ou EE qui ne sont pas publiés dans la zone de téléchargement publique pour CE ou dans la zone de téléchargement client / protégé pour EE. Cela nécessiterait que Magento établisse une politique cohérente pour que TOUS les correctifs soient mis à la disposition de TOUS les clients et que ceux-ci soient publiés là où nous pourrions les atteindre.

Donc, je ne pense pas qu'il existe un moyen d'automatiser à 100% cela jusqu'à ce que des changements se produisent du côté de Magento, malheureusement.

L'une des façons dont j'ai abordé cela lorsque je faisais beaucoup de mises à niveau et que j'essayais de systématiser le processus était de réellement valider les correctifs directement dans votre référentiel de code principal que vous utilisez pour comparer.

Cela a en fait deux avantages:

1. Plus de faux positifs apparaissant dans vos diffs.

2. Disons que vous avez un site qui n'a pas un certain correctif. Vous pourriez dire que c'est un problème car il apparaîtra comme du code manquant dans votre diff même si techniquement ils ne manquent de rien par rapport à un nouveau téléchargement non corrigé. Mais en fait, il leur manque un correctif est en fait un problème qui devrait être résolu - il est donc parfait qu'il apparaisse dans votre diff pour que vous puissiez le corriger avec la mise à niveau.

Je ne pense pas qu'avoir un Magento dans votre référentiel de projet soit une bonne idée au départ, au cas où vous gérer plus de 2-3 clients. Comme il est toujours plus facile de gâcher les correctifs système appliqués avec les hacks de base.

La meilleure option, à mon avis, est d'avoir un miroir de dépôt Magento de compositeur avec des balises de version, qui pointent vers une version particulière de Magento avec les éventuels correctifs officiels appliqués.

De plus, il serait plus facile de maintenir vos propres correctifs dans des fichiers, comme Mage_Core_Model_Config pour les sites Web à forte charge et certains autres, en introduisant leur versement via composer avec un numéro de version correspondant à votre versement Magento.

Donc, dans ce cas, votre mise à niveau de tous les projets client vers un code Magento corrigé ne se traduira que par un bump de version de votre fichier compositeur. Garder également le code du projet en dehors du noyau, forcera vos développeurs à ne pas pirater le noyau.

Quant à la définition d'un patch et d'un hack, je préfère l'appeler comme ceci:

1. Un changement dans le fichier core d'origine par le fichier de patch officiel - c'est un patch
2. Un changement dans le fichier core d'origine par votre équipe - c'est un hack.
3. Un changement dans le fichier de base copié local à des fins de correction de bogue - c'est un correctif
4. Un changement dans le fichier core copié local pour fournir de nouvelles fonctionnalités - c'est un hack

Ainsi, en déplaçant le noyau vers un référentiel séparé, vous vous assurerez que vous n'avez que la version corrigée conformément à l'élément 1. Et vous pouvez facilement installer vos propres correctifs sur composer dans le pool de code local, de sorte que vous avez tout conformément au point 3. Dans le cas de 2 et 4 vous pouvez créer un hook de validation git dans le référentiel de projet pour interdire toute validation de code dans ce répertoire.

Je regarde le fichier des correctifs appliqués dans ce /app/etc/dossier et je recule. Mais comme j'ai appris de la mise à niveau, je peux simplement supprimer le fichier sur une version contenant le fichier corrigé et la prochaine fois qu'il sera corrigé, il sera propre.

Tout ce qui vient de Magento, j'appellerais un patch. Tout le reste est un hack.