Configurar una tienda Magento no es solo una cuestión de desarrollar extensiones autoinstalables, sino que también requiere muchas operaciones de "entrada manual", como la creación de atributos de edición final, categorías, productos, páginas de CMS de reglas de precios, etc., sin mencionar todos Los cambios en la configuración del sistema.
Quisiera su ayuda para delinear la mejor estrategia cuando se trata de implementar una tienda Magento desde el desarrollo hasta el entorno de producción y puesta en escena.
Una estrategia mía es la de escribir un "módulo de implementación" que crea mediante programación las entidades mencionadas anteriormente, pero es una tarea que requiere mucho tiempo y, a veces, me parece un poco exagerado.
Recientemente comencé a usar Selenium IDE para reproducir tareas de administración, pero el tiempo requerido para configurar todas las suites de prueba no está lejos del mencionado anteriormente.
Quizás una solución óptima podría ser el uso de un módulo capaz de hacer una instantánea de un Sistema Magento que le permita elegir qué implementar.
Entonces:
- ¿Cuál es su estrategia para la implementación?
- ¿Existe un módulo capaz de hacer una instantánea de un sistema Magento que le permita elegir qué implementar?
- Si tal módulo no existe y siempre que dicho módulo sea una solución razonable, ¿hay alguien interesado en dar su contribución para desarrollarlo?
¡Gracias!
Respuestas:
Mi opinión es escribirlo todo. Por lo general, tengo un módulo de configuración base para cualquier cosa que no esté directamente relacionada con módulos específicos funcionalmente. (ejemplo, la creación de reescrituras de URL personalizadas para la URL del sitio anterior a la nueva URL del sitio) y agregue todo lo relacionado con un módulo a sus propios scripts de instalación.
La mentalidad detrás de esto es que si el sitio necesita ser reinstalado, usando una nueva base de datos, entonces todo vuelve como lo tenía. Esto también ayuda en el hecho de que actualizo periódicamente el sitio uat con una copia de la base de datos en vivo. Los módulos en uat luego continúan funcionando a medida que vuelven a ubicarse en sus configuraciones.
Los cambios en las tarifas postales, las reglas del carrito, etc. (básicamente cosas que los clientes se administran a sí mismos en admin) se consideran 'datos volátiles' y no están programados. Esto incluye datos del producto. El cliente tiene la opción y se le recomienda probar primero las nuevas importaciones en el sitio uat.
Se les dice a los clientes que no creen atributos, sino que los creen a través de una solicitud de ticket. Esto me permite también recopilar información sobre cuál es la intención del cliente para el atributo, y a veces tengo una mejor sugerencia, o puedo crear un mejor código, ya que tengo un control sobre qué atributos existen, además de los atributos seleccionables, asegurarme de que los datos estén limpiar.
Sí, las secuencias de comandos tardan más, pero llevará más tiempo recrear la configuración de un sitio completo manualmente más tarde. También puede ser vergonzoso si olvida algo y hace que el sitio no funcione correctamente, o si un nuevo desarrollador trabaja en un sitio local al que le falta una configuración de configuración crucial.
fuente
Había estado haciendo algunas investigaciones hace varios meses. Aquí están los sitios que puede consultar.
URL base de Magento e instalaciones dedesarrollo
/ preparaciónMagento Development and DeploymentMagento Git Guide and Work Flow
Volcado más rápido de una base de datos Magento MySQL para ramificar
fuente
Me gustaría agradecerles a todos ustedes porque sus consideraciones me han inspirado y empujado a desarrollar una extensión, llamada "Mageploy" con la intención de resolver el problema de mantener sincronizados diferentes entornos.
http://www.mageploy.com
Mageploy todavía tiene que extenderse, estar bien documentado y probado completamente, incluso si ya lo estoy usando en un par de proyectos que tienen algunos beneficios.
Es de código abierto y cualquier ayuda o sugerencia será apreciada.
Saludos
fuente
Con respecto a la instalación de scripts y la creación de entidades, mi sensación general es que si un módulo lo requiere o espera, debe crearse como parte de un script de instalación.
Recientemente, en términos de desarrollo / etapa / producción, utilizamos el sitio de preparación como la copia maestra de la base de datos para el contenido, ya que significa que el cliente puede colaborar. En el pasado, probablemente el mayor problema que hemos encontrado es coordinar la entrada de contenido con el cliente, particularmente en lo que respecta a la carga de productos.
¿Cómo creías que funcionaría la instantánea? Creo que en un mundo ideal, tendrías una herramienta que mostrara la diferencia entre dos bases de datos en tipos particulares (productos, categorías, CMS, etc.) y te permite fusionar los cambios entre sí, pero no conozco nada disponible como ese.
fuente
En mi opinión, crear y editar atributos, categorías, productos, reglas de precios no tienen nada que ver con una "estrategia de implementación". Todos estos artículos son bastante exclusivos de una tienda y, en la mayoría de los casos, exigen un análisis y una investigación adecuados de los productos que usted se van a vender
Si está creando tiendas "de talla única" con una configuración similar de todos los elementos que menciona, podría simplemente exportar una "instantánea" de su base de datos después de haber realizado toda la configuración que necesita para cada tienda.
fuente
Me gustaría agregar dos excelentes herramientas para ahorrar tiempo:
fuente