Visión de conjunto:

Esta pregunta se hizo originalmente y luego se cerró en StackOverflow . Decimos en meta , que aquí está el lugar correcto para esta pregunta.

Esta pregunta está a favor de ayudar a muchas personas a encontrar la manera correcta de estimar las actualizaciones de Magento.

La pregunta:

Me interesa saber cómo mide el tiempo necesario para la actualización de Magento. Supongo que la mayoría de ustedes tuvo dificultades para responder a la pregunta del cliente: "¿Cuánto tiempo llevará actualizar mi tienda Magento?"

Por lo general, el cliente necesita escuchar solo un número, por ejemplo: "Tomará X horas y costará Y dólares".

La idea principal detrás de la pregunta es sobre el aspecto técnico y qué verifica como desarrollador para hacer sus propios cálculos para las actualizaciones de Magento.

Creé la siguiente lista de verificación, solo para mis propios cálculos:

• ¿Se toca el núcleo de Magento?
• ¿Se toca el esquema de Magento DB?
• ¿Tenemos datos inconsistentes en el DB?
• ¿Cuántas extensiones personalizadas están instaladas en el grupo de códigos local y comunitario?
• ¿La extensión personalizada es compatible con la última versión de Magento?
• ¿El desarrollador del tema utilizó el archivo local.xml para las directivas de diseño, o simplemente copió los archivos xml de la base / default / layout al directorio de diseño del tema personalizado?
• ¿Tenemos obsoletas directivas de diseño / métodos de bloqueo en los archivos xml de diseño?
• ¿He desarrollado esta tienda Magento?

¿Cree que me falta algo y, en caso afirmativo, le gustaría compartir conmigo y la comunidad sus puntos adicionales para la lista de verificación?

La estimación de la actualización de Magento es un proceso de recopilación de información sobre las modificaciones aplicadas a la instalación que está a punto de actualizar, verificando si esas modificaciones pueden causar un problema y luego evaluando cuánto tiempo se requiere para solucionarlas.

Todas las modificaciones se pueden dividir literalmente en fuera de núcleo y en núcleo .

Las modificaciones fuera del núcleo son aquellas que no se sobrescribirán con la actualización. Esas son extensiones de terceros , archivos principales colocados en el ámbito local (aplicación / código / local / Mage) y un tema personalizado .

Las modificaciones in-core se aplican directamente en los archivos core de Magento (aplicación / código / core), archivos de localización (app / locale / en_US), plantillas centrales y algunas cosas como javascripts , bibliotecas externas que rara vez se personalizan, sin embargo, deben tenerse en cuenta .

Modificaciones fuera del núcleo

Extensiones de terceros

Durante las actualizaciones, las extensiones de terceros son la principal fuente de problemas. Lo que significa que más extensiones tiene más tiempo que necesitará para analizarlas.

Lo primero que debe verificar es si la funcionalidad proporcionada por la extensión aún no está implementada en una versión de Magento a la que está actualizando. Por ejemplo, algunas extensiones como Yoast_CanonicalUrl, Mxperts_CustomerAddresso Fontis_Wysiwygfueron ampliamente utilizadas en Magento 1.3.xx y anteriores, pero ahora son parte de la funcionalidad principal de Magento y ya no son necesarias.

Entonces es una buena idea verificar (pregúntele a su cliente) si realmente necesita todas esas extensiones que tiene. Es posible que haya algunas extensiones que instaló pero que realmente nunca usó. Entonces, en este punto, es bueno hacer una especie de limpieza.

Entonces, una cosa importante para verificar es la compatibilidad de cada una de las extensiones restantes con una versión de Magento a la que se está actualizando. En caso de que algunas extensiones no sean compatibles y no haya extensiones similares disponibles, tendrá la difícil elección de perder alguna funcionalidad o modificar extensiones existentes para hacerlas compatibles.

Nota: No modifique la extensión de terceros directamente, pero cree una nueva extensión que extenderá una obsoleta y luego establezca una dependencia en un XML de arranque de la nueva extensión.

Después de todo esto, se puede proporcionar el análisis real de cada una de las extensiones restantes. Siempre comenzará con el examen del etc/config.xmlarchivo. Hay 3 cosas que debe buscar:

• La reescritura de clases no es una técnica limpia en sí misma, pero en algunos casos no hay otra forma. Entonces, si se cambió la clase reescrita en la nueva versión de Magento, esto podría ser un problema potencial.
• Es menos probable que las actualizaciones de diseño causen un problema con su actualización, pero aún así si la extensión hace referencia a un bloque que está en desuso en una versión más reciente de Magento, tendrá que solucionar esto.
• Las actualizaciones de SQL son una fuente muy subestimada de problemas durante las actualizaciones. El problema ocurre cuando la extensión de terceros está creando una clave externa que hace referencia a algún campo en la tabla predeterminada de Magento. Como resultado, este campo está bloqueado de modificaciones. Y luego, si el script de instalación nativo intentará actualizar este campo, fallará en silencio. Después de eso, cada siguiente script de instalación que haga referencia a este campo bloqueará su actualización.

aplicación / código / local / Mage

Una vez que haya terminado con sus extensiones, es hora de echar un vistazo a su app/code/local/Magedirectorio. Aquí encontrará los archivos principales modificados movidos a un localámbito. Cada uno de ellos seguramente le costará algunas canas porque nunca se sabe (si no fue usted quien los puso allí) qué se modificó allí y por qué motivo. Por lo tanto, debe comparar cada uno de ellos con un origen y migrar la funcionalidad agregada al archivo correspondiente de la nueva versión.

Tema personalizado

La última modificación fuera del núcleo es el tema personalizado. Puede parecer que esto no es un gran problema, pero de hecho es un área gris. El tema base de Magento se está modificando de una versión a otra y cada tema personalizado debe imitar algunas de esas modificaciones. Lamentablemente, no hay una bala de plata para determinar qué buscar y qué se debe migrar. Así que prepárate para algunas sorpresas importantes y pequeñas críticas después de tu actualización.

Modificaciones en el núcleo

En el mundo perfecto no hay ninguno. Pero cuando tienes una instalación de Magento después de que ha sido abusada por desarrolladores externos, que ofrecen mucho a bajo precio, puedes esperar cualquier cosa. Por lo tanto, las modificaciones internas son las que se sobrescribirán durante el proceso de actualización. En la mayoría de los casos, no producirá ningún error, pero como resultado, perderá la funcionalidad que se agregó de una manera tan brutal.

La única forma de detectar modificaciones internas es comparar todos los archivos de su instalación de Magento con archivos limpios de la misma versión. Recomiendo hacerlo con git. ¿Por qué? Simplemente porque manejará todas las líneas nuevas y espacios en blanco muy bien.

Incluso si su instalación de Magento no está bajo git, aún puede copiar sus archivos en un directorio separado y luego ejecutar git init. Luego realice la confirmación inicial, copie los archivos Magento “limpios” y ejecútelos git status. Obtendrás algo como esto:

Ahora, dependiendo de la cantidad de archivos modificados que puede ejecutar git diffen cada archivo o en todo el lote a la vez. Esto le dará una referencia completa de todas las modificaciones internas realizadas. Si tiene alguna visualización de git como phpStorm, la vida es mucho más fácil para usted:

Le sugiero que haga git diff > changes.txtsiempre una lista de modificaciones a mano.

Al tener la lista de modificaciones principales, puede estimar qué se debe transferir a la nueva versión y cuánto tiempo se necesitará para hacerlo.

Ahora me gustaría dar algunos consejos para una actualización real. Este proceso está bien documentado, por lo que no escribiré qué comandos ejecutar y dónde hacer clic. Sin embargo, quiero hacer hincapié en varias cosas importantes:

• Asumimos que está actualizando su entorno de desarrollo. Ejecutar la actualización en su servidor de producción es un suicidio.
• No dejes que cambien nada en producción mientras estás actualizando. Ponga su Magento bajo control de versiones o incluso archivos temporales de bloqueo de escritura.
• Deshabilite todas las extensiones de terceros, pero tenga en cuenta cuáles se deshabilitaron inicialmente, por lo que no las habilitará después.
• Compruebe si hay una secuencia de comandos de limpieza de Magento ejecutándose en el servidor. De lo contrario truncar todas las tablas a partir de dataflow_*, log_*, report_*.
• Vuelva al tema predeterminado en el tiempo de actualización.

Después de completar la secuencia de comandos de actualización:

• Hacer referencia a lo changes.txtque hizo antes de migrar todas las modificaciones en el núcleo que realmente valen la pena.
• Migre las app/code/local/Magemodificaciones encontradas antes de la actualización.
• Uno por uno habilita extensiones de terceros.
• Vuelva a colocar su tema y compare exhaustivamente el resultado con el servidor de producción.
• Implemente en producción una vez que esté satisfecho con el resultado.

Conclusión

Sé que todo esto suena aterrador, pero si está actualizando regularmente, manteniendo su núcleo limpio e instalando extensiones solo de proveedores en los que realmente confía y solo si realmente las necesita, no enfrentará la mayoría de las dificultades descritas en este artículo. Mantenga su Magento EcoSystem saludable y será recompensado.

Post Scriptum

En casos muy complicados, tiene sentido comenzar de nuevo con una nueva instalación de la última versión de Magento y migrar el tema y la funcionalidad de su tienda paso a paso. Definitivamente, esto llevará tiempo, pero al final tendrá un sistema Magento saludable con plena conciencia de lo que está sucediendo.

En términos generales, el código Core nunca debe tocarse durante el desarrollo. Hay muchos mecanismos en Magento para permitirle solucionar cualquier problema, incluso errores internos. Dicho esto, también hay otros problemas a tener en cuenta.

1. Hace ningún código del núcleo de anulación módulos locales de la comunidad o (se puede buscar en la carpeta de módulos para <rewrite>, y es una mala práctica, ya que realmente debe utilizar código no intrusiva, como eventos)
2. Magento intenta mantener el código compatible con versiones anteriores, pero a veces el código cambia significativamente (se puede encontrar aquí ), si los cambios incompatibles con versiones anteriores son muchos, eso podría agregarse al proceso.
3. ¿Es fácil / posible duplicar el código en un entorno de desarrollo? si es así, simplemente ejecutar la actualización y las pruebas podrían ser todo lo que se necesita.
4. ¿Se necesita la actualización? ¿Hay características en la nueva versión que el cliente no puede dejar sin? Cualquier problema de seguridad (muchas veces Magento también proporciona parches posteriores)

En lo que respecta a la plantilla, por experiencia previa puedo decirle que apenas se rompe, a menos que el desarrollador se volviera loco con la codificación de la plantilla (que de todos modos debería estar en bloques).

Aquí hay algunas cosas a tener en cuenta:

• Verifique si el tema es compatible (verifique si hay una codificación extensa en los archivos de plantilla; a veces los desarrolladores junior hacen esto)
• Verifique cómo se almacenan los medios (si están utilizando CDN, etc.)
• Compruebe si hay algún método especial de almacenamiento en caché (APC Memcached, etc.)

Una forma de manejar este tipo de solicitud del cliente es hacer una revisión de la estimación.

Esto implica decirle al cliente que pasará un tiempo (facturable) mirándolo y le dará un plazo / costo más preciso para realizar el proyecto.

Seguir esta ruta los beneficia a usted y al cliente.

El cliente generalmente se sentirá más confiado en su estimación y respetará sus recomendaciones, lo que a su vez lo beneficiará al reducir el posible estrés.

Revisión estimada:

La revisión de la estimación real sería algo así:

• Volcar la base de datos en vivo e importarla en una máquina de desarrollo
• Copie los archivos magento de su máquina en vivo a su máquina de desarrollo
• Asegúrate de que todo esté bien y funcionando
• Intente la actualización y realice algunas pruebas iniciales para ver qué podría estar fallando

Este proceso debería tomar un promedio de dos horas facturables y le dará una visión muy necesaria del sistema en cuestión.

Hemos realizado varias actualizaciones en Magento CE, la peor fue de 1.3 a 1.7, lo que nos llevó casi 4 días completos. La estimación inicial fue de 1-2 días. Supongo que la actualización de 1.xa 2.x será una tarea igualmente grande e incluso si el equipo central proporcionará herramientas de migración, podría ser más limpio comenzar desde cero.

Quiero agregar una cosa a las excelentes respuestas dadas anteriormente:

• Compruebe si hay un VCS y un proceso de implementación adecuado.

No haré una actualización sin los procesos adecuados y la posibilidad de retroceder cuando ocurran problemas (aún más si no trabajé en el sitio antes). Alrededor del 90% de los clientes que se acercan a nosotros para una actualización de Magento (que no han sido nuestros clientes antes) solo tienen un entorno en vivo sin ninguna prueba / puesta en escena, VCS en absoluto.

La integración con otras entidades es una cuestión importante sobre la cual preguntar. Esto es algo que es posible que no pueda detectar mirando el sitio: es común que los clientes tengan sistemas de back-end que obtienen órdenes a través de la API de Magento, por ejemplo, y si no manejan la continuidad de esa integración mientras lo actualizan puede meterse en un lío

Cuando revise los componentes, busque los que hablan con otros sistemas; cada uno de estos será difícil de probar porque no desea enviar accidentalmente los datos de prueba a un sistema en vivo. A menudo existe un punto final de prueba que los desarrolladores originales utilizaron, pero es posible que ya no tenga esa información al actualizar.