En el primer post de la serie había comentado que la intención era un post semanal. Claramente eso no sucedió. (Veremos si puedo revertir eso)
Hasta este momento, había escrito sobre el motivo del proyecto y sobre las opciones evaluadas y los criterios aplicados.
Hoy toca convertir esto en un plan de trabajo, aunque sea de alto nivel. Para eso voy a intentar graficar (si aplica el término) el cómo he ido descomponiendo el proyecto.
Partimos de lo que muchos llaman el upgrade.
Usar el término upgrade para el salto de Magento 1 a Magento 2 me ha generado cierto rechazo desde el día 0. Si bien podría aceptar la idea del upgrade en lo funcional (ya que funcionalmente es la misma plataforma y en varios casos si hay una mejora), en lo técnico es un cambio de plataforma.
En términos generales, si nos referimos al código de los módulos o themes usados, nada de eso servirá. Todo aquello que no sea propio del core o de módulos de terceros, habrá que programarlo otra vez. Y está bien que así sea.
Volviendo un poco a la intención de planificar cómo llevar el proyecto adelante, la primera organización que se me ocurrió fue la obvia.
Esta podría ser la división por defecto de cualquier cambio de plataforma. Crear la tienda en la nueva opción y migrar los datos. En el caso de esta tienda, voy a tener un tema más a tener en cuenta.
El por qué de ese tercer, si se quiere, subproyecto, está relacionado con la herramienta de migración que provee Magento y la versión de la tienda.
Quizás podría agrupar algunas cosas más en un cuarto grupo pero me pareció que en este caso, considerando las variables que ya mencioné con anterioridad, estará bien.
Vayamos ahora un paso más hacia adentro de cada subproyecto o grupo de tareas.
En cada uno de ellos ubiqué, a su vez, la macro de las tareas a ejecutar.
En este grupo estarán todas las tareas relacionadas a la creación de la nueva versión de la tienda bajo la nueva plataforma.
Incluí también (cosa que podría haber estado aparte en un escenario de mayor tamaño) las tareas de inicio de proyecto.
Lo primero será crear un nuevo repositorio y agregar la última versión estable de Magento Open Source (hoy la 2.3.3).
Lo siguiente será configurar mi entorno de trabajo. Dado que lo tengo dockerizado y tengo varias cosas ya listas para poner a funcionar con un par de clicks, esto no debería ser un problema (ya veremos al final cuánto tiempo toma).
Finalmente, una tarea para crear y configurar un servidor de staging, para que el dueño de la tienda pueda validar que todo va por buen camino.
Lo siguiente serán las tareas de la creación del nuevo tema/diseño. En realidad, aquí se mantendrá el estilo de la tienda actual, pero dentro del layout de Magento 2.
En este caso, por su simplicidad, he preparado una tarea por cada sección (un concepto medio raro de sección ya que me refiero a Homepage, Category view, Product view, Cart, Checkout, Seach, Customer account, etc, etc).
Aquí no debería haber grandes complicaciones ya que es casi todo lo que viene por defecto, salvo algunos.
Cuando se trate de funcionalidades vamos a necesitar aprender a jugar un juego al que quizás no estábamos acostumbrados (y que debería ser práctica habitual).
Lo primero que tuve que hacer fue listar las funcionalidades no nativas que tiene la tienda. En esa lista, agrupé las funcionalidades en 3 categorías:
- Las necesarias para salir a producción. Son las que no pueden faltar porque afectan a funcionalidades críticas de la tienda.
- Las deseables, que son aquellas que queremos para nuestra tienda pero no son un bloqueo para salir a producción. Son funcionalidades que podríamos agregar una vez lanzada la nueva versión de la tienda.
- Y finalmente las prescindibles. Este es el grupo que creo deberíamos controlar de forma regular. Aquí se listan las extensiones que no agregan valor y que deberán ser ignoradas (o removidas del proyecto).
Siendo que la cantidad de módulos aquí es bastante baja, el trabajo es simple. No manejar de forma adecuada esta etapa de clasificación puede convertirse en un obstáculo.
Muchas veces estamos acostumbrados a un módulo en particular o un proveedor de funcionalidad determinado, pero quizás si paramos a revisar esa opción y las alternativas, vamos a poder aplicar mejoras cualitativas (y cuantitativas si logramos reducir la cantidad de código de terceros dentro de la tienda).
Luego de algunas experiencias, con aciertos y errores, opté por tener como política que si el negocio plantea sin dudar que «necesito todo lo que tenía tal cual lo tenía», es necesario invertir algo más de energía en esas funcionalidades y estudiar mejor cada caso.
El siguiente subproyecto será el de la migración específica de datos.
Al comienzo mencioné la herramienta de migración propia de Magento: el Data Migration Tool. (¿el, la?)
La herramienta es en realidad un módulo que debe instalarse del lado de Magento 2. El módulo posee varios archivos XML (¡sorpresa!) que permiten configurar desde la conexión a las bases de datos hasta los mapeos de entidades, atributos, tablas, etc.
La base de datos debe cumplir un único requisito: ser de una versión compatible por la herramienta. Por compatible me refiero a debe ser de un Magento Open Source 1.6 o superior, o de Magento Commerce 1.11 o superior.
Luego, como recomendación, se sugiere que la base de datos de Magento 1 se encuentre físicamente en el mismo servidor que la base de datos de Magento 2, para evitar problemas de latencia. Esto tiene especial significado cuando se trate de bases de datos de dimensiones importantes.
Una vez instalado el módulo, contaremos con algunos comandos adicionales en la consola de Magento.
Son esos comandos los que nos permiten migrar los datos.
La etapa final de la migración de datos tiene que ver con el control de los datos entre ambas versiones de la tienda y con la ejecución de smoke tests que nos ayuden a corregir cualquier error que pudiera haber quedado.
El tercer subproyecto, como mencioné al comienzo, tiene que ver con las limitaciones de la herramienta de migración y la versión de la tienda que tengo para el proyecto.
El punto central será:
En esta parte voy a tener que lidiar con varios detalles técnicos. La versión de PHP de que soporta la tienda ya no está disponible.
Va a ser necesario hacer un upgrade manual hasta lograr la versión de la base de datos necesaria.
Aquí será Docker quien venga al rescate ya que necesitaré un servidor con los requerimientos de PHP específicos de 1.4.2.0 para poder hacer le upgrade hasta, al menos, 1.6.0. (Por suerte las viejas imágenes de Ubuntu LTS son accesibles vía Docker).
Habiendo separado todo en tareas, en este momento el proyecto tiene unas 29 tareas listas para ser atacadas.
Ahora si, el próximo paso será técnico.