¿La mejor práctica para realizar una actualización de Magento?

Question

¿Cuál es la mejor práctica para hacer una actualización de Magento (de una instalación de Magento mal mantenida).

pienso en cosas como la siguiente:

• un vistazo a los módulos sobreescribe los plenos en app/código/local - comparar los archivos con la versión antigua y las transmitirá puertos a la nueva versión de Magento
• Compare las plantillas
• comparar archivos XML de diseño (si es que se han copiado directamente a la carpeta de temas personalizados y no se utilizó layout.xml simple que contiene sólo las actualizaciones reales)
• comparar los métodos de las clases reescritas a los métodos de la clase original

El problema principal es: cuando se difieren archivos en instalaciones Magento antiguas mal mantenidas, nunca se sabe qué versión tenía el archivo original que se copió. Algunas veces traté de identificar la versión anterior echando un vistazo a los derechos de autor de Magento en el comentario del archivo.

Para evitar problemas durante la actualización que normalmente hacemos lo siguiente:

• Evitar reescrituras, eventos uso en lugar
• Si vuelve a escribir son necesarias, no tratar de copiar el código, pero llamar a parent ::() para mantener sólo la funcionalidad necesaria en la clase sobrescribe
• Si el código copiado es necesario, utilice un marcador comentario como [Mycompany BEGIN] ... [Mycompany END]
• no copie archivos de diseño enteras pero el uso de un solo layout.xml que hace sólo las actualizaciones.

¿Pero cómo hacer una actualización si no se toman esas precauciones?

Answer 1

Lo primero que haría es copiar el sitio a un entorno de desarrollo. Ahora haz una copia de seguridad de eso, para que puedas restaurarlo en cualquier momento que lo necesites. También en este punto pondría el sitio en vivo en el bloqueo de código. No más cambios en el código a menos que sea absolutamente necesario (y si hay cambios, tendrá que duplicarlos en el nuevo entorno de desarrollo)

Ahora que tiene una copia segura del sitio web disponible para jugar, ahora la diversión comienza

Lo primero que haría es desplegar una copia de la versión original de Magento que esté ejecutando. Haga una diferencia en/app/code/core entre la versión estándar y la que tiene actualmente. Esto te dirá cuáles son tus diferencias. Intentaría mantener todas las funcionalidades que tiene actualmente, mientras recupero el núcleo.

Esperemos que en este punto tenga una instalación bastante limpia de Magento. Podrías considerar llevar esto al servidor en vivo, pero tengo la sensación de que debiste haber hecho muchas maniobras para llegar tan lejos, así que puede que no sea una opción viable.

Ahora haría una copia de seguridad por separado del sitio de desarrollo para que pueda volver a este punto si es necesario.

Ahora, intentaría la actualización en el sitio de desarrollo. Espero que todo salga bien y no tenga problemas con la actualización. Si no lo hace, haga las correcciones que necesita y continúe desde allí.

En este punto, debe tener una base de código que sea estable con la actualización. Haz una copia de seguridad en vivo otra vez (solo para estar seguro), inserta el nuevo código y espera que todo salga bien.

Answer 2

Comenzaré por señalar que el contenido de su pregunta indica una comprensión clara de (lo que al menos considero que son) las mejores prácticas.

En cuanto a las posibles versiones múltiples de origen: el objetivo de una actualización de software es tener las nuevas clases y métodos en su lugar, punto. Eso significa (como usted mencionó) portar cualquier personalización independientemente de cómo fueron implementadas.

Fuera de la diferencia diligente, la mejor técnica para su situación desafortunadamente será prueba de regresión - verificando la salida generada para vistas múltiples.

Podría muy bien ser el caso de que es posible que tenga que despejar, es decir empezar con una instalación limpia y llevar activamente en la funcionalidad personalizada & tematización que todavía se considere necesario. Esto puede no parecer como el enfoque más eficaz, pero aquí son los beneficios que creo que superan la aparente sobrecarga:

1. Va a estar en control de todo comportamiento personalizado sin sorpresas
2. Usted puede estar seguro de una código base sana de origen único
3. en algún momento al cliente que convertirse en el propietario del código, y un enfoque de lista blanca/afirmativa para reintegrar personalizaciones parece la mejor manera de estar seguro de que su propiedad es lo que esperas.

Answer 3

Como otros han notado, la clave aquí es hacer que sea comparable con una instalación limpia, así que esto es lo que haría con la ayuda del control de versiones.

1. obtén la versión limpia de Magento que tienes actualmente y no olvides compararla. O utilizar un espejo Git existente de Magento (ver más http://blog.speedupmate.com/post/4063307705/magento-git-mirror)

2. estableció un acuerdo de recompra maestro basado en 1. aquí y tenerla a mano,

   formuladas en los comentarios: Su objetivo final es tener un núcleo limpio con todos los archivos en git que están presentes en los archivos de instalación de magento. Eso es necesario para que pueda comparar todo contra la instalación limpia. Administración de cambios principales, archivo de árbol central (archivos existentes, no existentes, agregados). Puede manejar sus excepciones con .gitignore (excluyendo medios, caché, todos los campos con alcance específico del servidor local.xml .htaccess). Me resulta fácil mover los archivos principales de Magento a un directorio diferente (no público) (como se explica aquí http://blog.speedupmate.com/post/9992573819/poor-mans-multisite-setup-for-magento) y eso me dará un estado de código donde .htaccess nunca entra en conflicto en la actualización. Tampoco incluyo medios en el control de versiones, el caché y todos los archivos temporales que genera magento. Esto le garantizará una ruta clara en las actualizaciones ya que puede deshabilitar todo durante el tiempo de actualización. Comparar el código más tarde le dará el alcance de las cosas que necesita para la vista general y puede estimar cuánto tiempo le tomará comparar las partes modificadas e iniciar la actualización.

3. ahora con su sitio existente y configuración de git en su lugar (para hacerlo comparable) haga un git init en su base de código y agréguele todo a git, esto repasará su configuración de git y hará que cada archivo sea comparable (las mismas líneas nuevas espacios en blanco, etc.) luego corrige los permisos de archivos para que sean iguales. Después de eso, puede eliminar la carpeta .git de su sitio, ya que solo usó git para hacer que los archivos sean comparables allí.

   Preguntado en comentarios: El punto aquí es hacer que git funcione para usted, como convertir todas las terminaciones de línea al estilo Unix e ignorar espacios en blanco, también puede ignorar los permisos en teoría, pero eso no es útil. representa un salto de línea entre los comandos

   git config core.autocrlf input \ git config core.eol lf \ git config apply.whitespace nowarn

   Ahora bien, si git init y añadir esas configuraciones y añadir todo a git luego, durante la comisión de git etapa reemplazará todas sus finales de línea de ventanas y toda esa basura a unificado y comparable Tenga en cuenta que el estándar de codificación zend sugiere terminaciones de línea de estilo Unix, sin embargo, usted También veo los archivos donde la biblioteca Zend no sigue sus propios estándares. El punto clave aquí es que necesita que sus archivos sean comparables para minimizar la carga de diferencia que tiene que hacer. Eliminará la carpeta .git después de que git haya formateado todos sus archivos de instalación defectuosos. Git solo se usa para automatizar el proceso "hacer cosas comparables" en este paso y nada más

4. revise su repositorio de pruebas basado en su repositorio principal en 1. y seleccione una rama con la versión que tiene actualmente y asígnele el nombre "testsomething" o lo que sea que necesite

5. elimine todo de la carpeta de comprobación y deje solo .git en su lugar para que esté vacío, pero el control de versión todavía existe allí. Estará en estado como se borra todo y esto es importante porque, de acuerdo con esto, sabrá qué archivos puede haber eliminado en su sitio incorrecto.

   Preguntado en los comentarios: Generalmente agrego espacios en blanco ignorando a git config (el alcance local o global está disponible) y dejo que git maneje eso por mí. Cuando trabajamos en equipos, siempre acordamos los estándares basados ​​en Zend: 4 espacios para pestañas, terminaciones de línea de estilo Unix y variables de configuración de git mencionadas en 3. y si se utilizan scripts de compilación, realizamos el formateo y validación de códigos con commit hooks.

6. movimiento en todos los archivos a un directorio vacío (nota que haya quitado el .git dir de su sitio existente después de su equiparación) de su f cked instalación de Magento (son comparables ahora) y ejecuta un git status > changes.txt . Este archivo ahora enumera cada diferencia que tiene, cualquier archivo nuevo que tenga, cualquier archivo eliminado, renombrado, etc. que tenga en su "instalación f cked up" contra el código limpio de Magento en el que se encuentra actualmente.

   Explicando basan en los comentarios: Por lo general no git status --porcelain

7. tener un archivo .gitignore en el lugar para ayudar a que descartes local.xml var/* o cada archivo/dir que no es necesario el control de versiones y también .DS_Store, .Thumbs.db y tus archivos de proyecto ide ide de git. No necesita todos los archivos multimedia y en caché y los archivos que son diferentes en cada servidor en el control de su versión.

Desde allí se debe la vista general que lista cuidadosamente y en base a esa lista debe:

• movimiento cada cambio núcleo de aplicación/código/local /, y obtenga el archivo modificado a su estado original (mantener el copiado uno y desechar los cambios en el núcleo con git checkout filename)
• movimiento cada plantilla núcleo cambiada y archivo de diseño a su propia carpeta de temas, y obtenga el archivo modificado a su estado original
• revertir o migrar cambios .htaccess o deci de si hay que conservar o descartar

Ahora usted todavía está en mal estado, pero se encuentra ahora:

• basado en núcleo limpia
• basado en el árbol principal versionado en una rama separada

Ahora puede beneficiarse al ser controlado por la versión, comparable y en una sucursal separada basada en su rama principal que tiene versiones de Magento que se pueden combinar. Intentemos actualizar, estos son los puntos clave del 100% de éxito al hacer esto.

1. primer paso sería desactivar toda la "basura" que ahora se ha separado a app/código/Mago locales// y para separar el tema. Si su núcleo está despejado y los temas pueden ser deshabilitados, no tiene código personalizado que interfiera con el proceso de actualización. Así que adelante con deficiencia:

   • todas las extensiones locales y las extensiones de la comunidad personalizados moviendo fuera de aplicación/etc/modules/a la carpeta temporal deja que sea app/etc/inactivo/
   • temas personalizados desactivar y activar base/predeterminado/
   • este es su beneficio al estar en un estado comparable. Usted sabe lo que es diferente y se puede desactivar esa y diagnosticar las cosas en base a que

2. ahora si tiene todas las versiones importantes en el árbol principal en tu repositorio etiquetado o ramificado separado a continuación, obtener la versión más alta es simplemente un comando de distancia : git merge "magento-vhateverthenextversionis"

   • de nuevo después de hacer esto "git status> changes.txt" le dará una lista de todos los archivos modificados entre sus versiones
   • ejecutar el sitio en el navegador va a realizar la actualización y dado que está en el tema predeterminado y no hay personalizaciones activadas, funcionará como un amuleto
   • repite la versión de actualización por versión y guarda el estado del código marcando en tu rama de prueba o crea una nueva rama para cada versión basada en la rama de prueba existente, de esta manera has guardado el estado limpio para cada versión de magento que tienes actualizado en el medio
   • de nuevo la ventaja adicional es que si lo haces con el control de versiones también puede deshacerse de los archivos que las nuevas versiones descartan y se puede eliminar fácilmente

3. si ha reiterado la 2.a su versión de Magento deseada a la última, entonces es hora de comer la "s * es" que ha heredado y hace el siguiente:

   • analizar todas las extensiones que tiene y ver si se pueden actualizar, si puede actualizar y activar si funcionan con el tema predeterminado
   • diff cada núcleo reescribe en la aplicación/código/local/Mage contra su versión original en forma nueva desde la aplicación/código/núcleo/Mage. Puede usar herramientas diff como winmerge.org o cambios (sea cual sea el sistema operativo y la herramienta que prefiera) una por una o carpetas completas diferentes
   • igual que con su plantilla y plantillas o diseños sobrescritos. Comparar con el original y fusionar los cambios en la nueva plantilla base y deshacerse de lo viejo DOM
   • a su vez sobre los cambios temáticos y extensiones de forma individual y depurar

4. si se llega a este punto, entonces usted ha hecho un chingo de trabajo, dependiendo de lo mal estado de la instalación es que puede tomar días. Pero bueno, ahora tienes un núcleo de magento limpio que está controlado por la versión, sobrescrituras separadas que están fusionadas y vistas, y todo en un tema separado que se puede deshabilitar.

5. La parte divertida es que si la siguiente actualización de magento está disponible puede silbar y agregarla como comparable a su árbol maestro y fusionar los cambios, saber qué cambia y tener un alcance claro sobre qué revisar y probar.