¿Cuál es la mejor estrategia de implementación?


82

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!


Esto podría indicar la necesidad de otra etiqueta o categoría de etiqueta. ¿Eres una tienda única o estás buscando sugerencias generales como proveedor de servicios? Si es lo último, cualquier respuesta tendría que estar salpicada con "depende de cuánto control quiera el cliente sobre los datos de la entidad".
puntos de referencia

Mi punto de vista es el de un desarrollador que pertenece a un equipo de desarrollo. Supongamos que estoy desarrollando una sección que necesita algunos datos para funcionar, digamos una estructura de categorías. Creo la estructura a través de Admin, hago el código y presiono mi código. Me pregunto si la mejor estrategia es también escribir y empujar el código que crea la estructura de categorías necesaria. ¿Qué sucede si la estructura o la configuración de mi categoría entran en conflicto con las de otros desarrolladores que presionaron las suyas? ¿Cómo manejo los conflictos? Ese es mi punto.
Alessandro Ronchi

@AlessandroRonchi Este es un punto discutible y un conflicto que nunca debería suceder. La estructura de su categoría no es algo que deba cambiar frívolamente, por lo tanto, un desarrollador no debe impulsar un cambio importante en su estructura, sin que los demás lo sepan. Si esto sucede, debe abordar su comunicación entre desarrolladores. Por lo general, la estructura de categorías de un sitio debe precisarse desde el primer día, y nunca más debe cambiarse, solo debe agregarse. Si necesita cambiarlo, no lo examinó correctamente la primera vez.
ProxiBlue

@dedmeet desafortunadamente, en el mundo que conozco y trabajo, las cosas cambian todos los días; los clientes cambian de opinión, los desarrolladores cambian de opinión, se producen cisnes negros. Tengo que estar preparado para los cambios; de todos modos, incluso si la estructura de categorías no necesita ser cambiada desde el primer día, es solo una pequeña parte de toda la parte y toda la parte es un proyecto de "trabajo en progreso" que se supone que debe cambiar para hacer las cosas.
Alessandro Ronchi

ok, concedido, trabajamos en un entorno siempre cambiante, pero sigo afirmando que no debería ocurrir un conflicto de estructura de categorías. No deberían existir múltiples ramas donde cada una cambia la estructura, eso solo conducirá a problemas y pérdida de tiempo de desarrollo. ¿Por qué el dev pasa un tiempo haciendo cambios en la estructura, mientras que dev b hace lo mismo en una estructura diferente, y ambos empujan su trabajo? Si la estructura debe cambiar, todos los desarrolladores involucrados en el proyecto deben estar involucrados en el proceso de determinar la nueva estructura. ¿Me puede dar un ejemplo para ayudarme a entender cuándo puede suceder esto?
ProxiBlue

Respuestas:


39

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.


1
Estoy de acuerdo con dedmeet. Cuando aprenda por primera vez a escribir todas las actualizaciones, puede ser más trabajo inicial, pero si tiene que aplicar las actualizaciones de configuración manualmente para 3-4 desarrolladores, etapas, uat y live, la coordinación y el trabajo real tomarán mucho más tiempo. Nuestro flujo de trabajo es bastante similar: si se necesita la configuración para una extensión (reutilizable), colóquela allí. Si la configuración es específica del cliente, colóquela en una extensión específica del proyecto. Una de las pocas excepciones son las reglas de carrito que no son divertidas de actualizar / crear.
Matthias Zeis

1
Acabo de lanzar un módulo que ayuda a crear el script de configuración requerido, eliminando así el trabajo mundano de tener que crear manualmente los scripts de instalación. El módulo utiliza una visualización de cuadrícula de la tabla core_config_data para permitir la selección de los valores de configuración para exportar. Haz mi vida un poco más simple, y espero que funcione para otros. proxiblue.com.au/blog/magento-config-data-generator
ProxiBlue

27

1
Gracias, los leeré todos y volveré con algunas consideraciones.
Alessandro Ronchi

He leído todos los recursos de dar; Ya conocía algunos de ellos, otros que no conocía son muy interesantes. Ninguno de ellos, de todos modos, es la solución a mi problema y he decidido esbozar una extensión que tratará de satisfacer mis necesidades. Gracias a todos los que me dieron valiosos consejos. Espero volver aquí con algunos resultados.
Alessandro Ronchi

Querido Alessandro, me gustaría ver tu camino, que también estoy buscando una técnica más cómoda.
Oğuz Çelikdemir

18

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


7

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.


1
"Con respecto a la instalación de scripts y la creación de entidades, mi opinión general es que si un módulo lo requiere o espera, debe crearse como parte de un script de instalación". Este es el punto más destacado a tener en cuenta y se aplica a la configuración. Mi prueba rápida: cuando necesito un nuevo desarrollador para clonar el repositorio e instalar el entorno, ¿qué debe existir para que el sistema funcione?
puntos de referencia

Compartir un sitio de preparación con clientes para colaborar en la configuración es genial en teoría. En la práctica, los clientes no le dicen todo lo que cambiaron el 99% del tiempo, lo que facilita arruinar algo. Podemos permitir que los clientes trabajen en cosas como reglas de carrito, categorías, productos o similares, pero no permitimos que interfieran con la configuración.
Matthias Zeis

6

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.


No, "una talla para todos" no es el punto; es la misma situación en la que nosotros, como desarrolladores, nos encontramos cuando llega el momento de fusionar nuestro código fuente con el de otro miembro del equipo de desarrollo: en ese caso tenemos sistemas de control de fuente que hacen la magia. Mi pregunta estaba más relacionada con la oportunidad de fusionar cosas "no dev", como la configuración y las configuraciones y entradas típicas de administrador.
Alessandro Ronchi

Ah ok, eso lo deja más claro
Rutger

Digamos que estamos creando un sitio web completamente nuevo, por lo que no hay problemas con datos antiguos, etc. Casi todo el tiempo, todos nuestros desarrolladores utilizan la misma base de datos para el desarrollo. Eso resuelve muchos problemas. Para otros casos, no tengo una mejor solución (todavía) que escribir todos los pasos necesarios en algún tipo de hoja de ruta / script y volver a aplicarlos todos después de la fusión. Si solo una persona es responsable de la configuración del administrador "magento core", estos no deberían ser muchos pasos. Una vez encontré esto, pero nunca lo he probado tinybrick.com/magento-modules/admin-tools/…
Rutger

2

Me gustaría agregar dos excelentes herramientas para ahorrar tiempo:

  • Para el desarrollo: PhpStorm IDE con el complemento Magicento
  • Para la implementación: Magentify , una receta de Capistrano para Magento

Gracias por informarnos sobre Magentify, no lo sabía y lo intentaré. Sin embargo, mi enfoque estaba más en sincronizar un entorno de desarrollo diferente que en la implementación en el sentido de publicar una base de código. Mageploy podría integrarse con Magentify, pero es una herramienta diferente, utilizada para mantener automáticamente una parte de los cambios en la base de datos alineados, independientemente de los ID específicos que son diferentes entre un entorno diferente. Atentamente, Alessandro
Alessandro Ronchi
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.