Estamos desarrollando módulos de forma activa y cuando promocionamos los cambios en nuestro sitio de producción, generalmente hay varios cambios de configuración que debemos realizar. Sería bueno automatizar esto ... ¿pensamientos?Magento: ¿Cómo puedo migrar los cambios de configuración del entorno de desarrollo al de producción?
Realice los cambios como parte de una instalación o actualización de la escritura en el directorio "sql" de su módulo. En el archivo "config.xml" de su módulo, incremente el número de versión de cada cambio coincidente y también recuerde completar el nodo <config><global><resources><MODULE_setup><setup>.
Debido a que el script se ejecuta en el contexto de Magento tiene acceso a toda la funcionalidad normal también, las actualizaciones no tienen que ser en forma de comandos SQL.
Estoy de acuerdo con su comentario, pero lo llevaría más lejos, es decir, "las actualizaciones ** NO DEBEN ** estar bajo la forma de comandos SQL". No he encontrado ninguna declaración DDL o DML que no se pueda ejecutar a través de las estructuras de configuración de Magento. Mucho más fácil para el control de versiones. –
Una pregunta de seguimiento es [aquí] (http://stackoverflow.com/q/4315660/471559). – clockworkgeek
No estoy seguro de si todavía es real, pero si se refiere a cambios en el sistema -> config, entonces es mucho más preferible utilizar dichos nodos config.xml en lugar de escribir actualización de base de datos.
Magneto procesa la tabla core_config_data en la estructura XML global, por lo que puede simplemente cambiar la estructura XML sin utilizar la tabla db para realizar cambios en la configuración del sistema.
Aquí es pequeño ejemplo:
<config>
<stores>
<french>
<design>
<theme>
<default>french</default>
<theme>
</design>
</french>
</stores>
<websites>
<base>
<design>
<theme>
<default>english</default>
<theme>
</design>
</base>
</websites>
</config>
En este ejemplo se cambia un campo de configuración para dos alcances en Magento. Es la definición del tema actual según el sitio web y la tienda actuales.
Así <stores /> nodo contiene los valores de configuración para una tienda particular. Donde cada elemento secundario se nombra con código de tienda y contiene datos de configuración en vista anidada. Y el nodo <website /> contiene valores de configuración para un sitio web en particular. Donde cada elemento secundario se nombra con el código del sitio web y contiene datos de configuración en la vista anidada también.
También hay disponible <default /> nodo para los valores de configuración en el alcance global. Pero será anulado por <stores /> y <websites /> si un valor particular es para un alcance.
Estoy haciendo cambios en la configuración solo a través de config.xml porque implementar el proyecto es mucho más fácil cuando solo necesita instalarlo a través del instalador de Magento sin hacer cambios en "Sistema -> Configuración".
Por lo que yo entiendo, esta técnica se puede usar solo para valores predeterminados que no existen o 'NULL' en la tabla db' core_config_data'. Si el valor existe, necesitamos escribir la actualización de la base de datos. ¿Estoy en lo cierto? –
@ v.kondratyuk, sí, tienes razón. En realidad, este enfoque le permite especificar el conjunto de datos predeterminado por tienda/sitio web/alcance predeterminado, que luego el usuario administrador puede cambiar. Siempre es bueno migrar la configuración a través de un archivo XML, si intercambia código entre desarrolladores en el equipo, o qa implementaciones. Si el desarrollador o algún otro usuario cambió un valor en DB, no debe afectar este cambio mediante la actualización de db, ya que puede afectar a las sesiones de depuración para otros desarrolladores en el equipo. –
A menos que Magento tenga algunos requisitos muy extraños cuando se implementa, diría que este es un posible duplicado de [PHP Site Deployment Suggestion] (http://stackoverflow.com/questions/2628835/php-site-deployment-suggestion) Básicamente, phing debería ayudarte. – Gordon