Cuando estoy en un proyecto de actualización del sistema, una de las cosas que hago es diferenciar el sistema de un cliente contra una nueva instalación de Magento. Estoy buscando hacks centrales o archivos adicionales que no son parte de Magento estándar para asegurarme de atrapar cualquier trabajo de mala calidad pero crítico para el negocio realizado por un profesional independiente, contratista, consultor o agencia anterior.
Sin embargo, una cosa que siempre me desconcierta son los parches. A lo largo de los años, Magento ha emitido parches "entre versiones", generalmente para abordar una solución de seguridad o un cambio en la API de un proveedor de envío / pago.
El problema es que, desde el punto de vista de una diferencia, los parches son indistinguibles de los hacks centrales, especialmente cuando no sabe qué parches (si los hay) se han aplicado al sistema.
Lo que lleva a mi pregunta.
¿Cómo diferenciar entre un hack core y un parche?
fuente
Esto es algo con lo que trato a menudo (y estoy trabajando en este momento), y desafortunadamente, hasta ahora es un proceso completamente manual: tenemos un proceso automatizado que marca cada archivo que podría modificarse como parte de nuestra auditoría automatizada inicial para Un nuevo cliente de soporte. Luego, hacemos que alguien diferencie esos archivos y descarte cualquier falso positivo obvio (es decir, cambios en espacios en blanco).
Luego, la parte divertida: un miembro senior de nuestro equipo que ha estado trabajando con Magento durante bastante tiempo tiene que echar un vistazo a los resultados para determinar si alguno de los archivos modificados podría ser el resultado de un parche. Hemos analizado la actualización de nuestro sistema para verificar todos los parches que conocemos / podemos tener en nuestras manos, y eso podría funcionar para CE, pero en EE es aún más desafiante, ya que el soporte de EE a veces emite parches directamente a clientes que nunca se publican de otra manera o se catalogan de manera consistente.
Entonces, cuando hacemos este nivel de revisión, confiamos en la experiencia pasada aplicando estos parches + sentido común (es decir, ¿es solo un cambio en el punto final de una API? Si es así, ¿ese punto final cambiado está presente en la versión actualizada? Si es así, fue un parche y puede ser ignorado).
Sería teóricamente simple aplicar todos los parches disponibles en la página de descarga de CE, etc., a cada versión aplicable de CE y verificarlos (para su información, no usamos diff para la primera pasada; usamos hashing, en en parte porque creamos esta tecnología en una herramienta que puede verificar remotamente un sitio sin necesidad de descargarlo primero). Eso descartaría la mayoría de los parches, pero todavía no ayuda para los parches CE o EE que no se publican en el área de descarga pública para CE o el área de descarga protegida / cliente para EE. Eso requeriría que Magento establezca una política coherente de que TODOS los parches estén disponibles para TODOS los clientes, y que los publique en donde podamos acceder a ellos.
Por lo tanto, no creo que haya una manera de automatizar esto al 100% hasta que ocurran cambios en el lado de Magento, desafortunadamente.
fuente
git diff depot/master origin/master. El desafío es el .gitignore. Otra opción es clonar la versión en un directorio separado y luego copiar elapp/code/coredirectorio de los sitios sobre él.git diff -wentonces te lo diré.Una forma de abordar esto cuando estaba haciendo muchas actualizaciones y tratando de sistematizar el proceso fue enviar los parches directamente a su repositorio de código central contra el que está utilizando la diferencia.
Esto en realidad tiene dos beneficios:
No más falsos positivos que aparecen en sus diferencias.
Digamos que tiene un sitio que no tiene un parche determinado. Se podría decir que es un problema porque aparecerá como un código faltante en su diff, aunque técnicamente no les falta nada en comparación con una descarga nueva sin parchear. Pero, de hecho, que les falta un parche es en realidad un problema que debe resolverse, por lo que es perfecto que aparezca en su diff para que lo solucione junto con la actualización.
fuente
No creo que tener un Magento en el repositorio de su proyecto sea una buena idea inicialmente, en caso de que administre más de 2-3 clientes. Dado que siempre es más fácil estropear los parches del sistema aplicados con hacks centrales.
La mejor opción, en mi opinión, es tener un espejo de repositorio Magento de compositor con etiquetas de versión, que apunte a una versión particular de Magento con posibles parches oficiales aplicados.
También sería más fácil mantener sus propios parches en los archivos, como Mage_Core_Model_Config para sitios web con mucha carga y algunos otros, al introducir su instalación a través del compositor con un número de versión que coincida con su instalación de Magento.
Entonces, en este caso, la actualización de todos los proyectos del cliente a un código parcheado de Magento solo dará como resultado un aumento de la versión de su archivo de compositor. Además, mantener el código del proyecto separado del núcleo obligará a sus desarrolladores a no piratear el núcleo.
En cuanto a la definición de parche y un truco, preferiría llamarlo así:
Entonces, al mover el núcleo a un repositorio separado, se asegurará de tener solo la versión parcheada de acuerdo con el elemento 1. Y puede instalar fácilmente sus propios parches sobre el compositor en el grupo de códigos local, de modo que tenga todo de acuerdo con el punto 3. En caso de 2 y 4 puede crear un enlace de confirmación git en el repositorio del proyecto para prohibir cualquier confirmación de código en ese directorio.
fuente
Miro el archivo de parches aplicado en esa
/app/etc/carpeta y trabajo al revés. Pero como aprendí de la actualización, simplemente puedo eliminar el archivo en una versión que tiene el archivo parcheado y la próxima vez que esté parchado está limpio.fuente
Cualquier cosa de Magento llamaría parche. Todo lo demás es un truco.
fuente