deployment - español - ecommerce con magento
Mejores prácticas para la implementación de Magento (5)
Después de muchas pruebas y errores, hemos creado un flujo de trabajo que nos queda bien:
http://www.dhmedia.com.au/blog/perfect-magento-workflow-using-git
Incluye administración de bases de datos, todo el código bajo control de fuente (con Git), implementaciones, sitios de etapas y desarrollo, múltiples desarrolladores, múltiples entornos, etc.
¡Espero que esto ayude a alguien!
Estoy buscando configurar un proceso de implementación para un sitio de Magento altamente personalizado, y me preguntaba cómo lo hacen otras personas.
Voy a configurar entornos de desarrollo, UAT y prod. Todos los archivos de Magento estarán en control de fuente (SVN). En esta etapa, no veo ningún requisito para cambiar la base de datos, por lo que las 3 bases de datos se mantendrán manualmente.
Específicamente,
- ¿Cómo aplicas las actualizaciones de Magento? (Individualmente en cada env, o en dev luego lanzar, o simplemente darse por vencido en las actualizaciones?)
- Qué archivos / carpetas dejan solos en cada entorno (por ejemplo, magento / app / etc / local.xml)
- ¿Usted restringe a los desarrolladores a la edición de archivos / carpetas específicos?
- ¿Se restringe a los diseñadores de temas a la edición de archivos / carpetas específicos?
- ¿Cómo manejas los cambios en la base de datos?
Archivos / carpetas del Diseñador de temas
Los diseñadores pueden restringir la edición de las siguientes carpetas-
app/design/frontend/your_interface/your_theme/layout/
app/design/frontend/your_interface/your_theme/template/
app/design/frontend/your_interface/your_theme/locale/
skin/frontend/your_interface/your_theme/
Archivos / carpetas de desarrollador de extensión
Los desarrolladores de extensiones pueden editar las siguientes carpetas / archivos-
/app/code/local
/app/etc/modules/<Namespace>_<Module>.xml
Gestión del entorno de la base
Como la URL base de la tienda está almacenada en la base de datos, no puede copiar bases de datos entre entornos. Las opciones incluyen-
- Anulando la url base en php. Artículo de blog sobre cómo configurar bases de datos de desarrollo y etapas
- Cambiar la URL base en la base de datos después de copiar. ( ¿Dónde está esto almacenado? )
- Hacer un MySQLDump o una copia de seguridad, luego hacer un reemplazo en la URL en el archivo SQL.
Puede evitar la DB-Manipulation (en alemán): http://blog.tudock.de/startseite/beitrag/2010/09/17/deployment-prozess-eines-magento-shops.html
Recomiendo usar git sobre SVN. Una bifurcación y fusión más fáciles significa que todos estos puntos serán más fáciles para usted.
Aplicación de actualizaciones: haz esto en el desarrollo Cree una sucursal (aquí es donde realmente brilla Git), aplique los archivos de parche o incluso mejor, descomprima una nueva versión de Magento y apúntela a su base de datos anterior. Sin extensiones todavía Abre el administrador en la nueva instalación de Magento y espera lo mejor. La actualización entre versiones menores probablemente no sea un problema. Probablemente tengas que volver a indexar después de todas las instalaciones nuevas. Realice una confirmación una vez que esto sea estable, luego agregue gradualmente a la rama sus extensiones y temas, realice cualquier ajuste de código y luego realice una confirmación después de que cada paso sea estable.
Archivos dependientes del entorno: .htaccess y app / etc / local.xml. Hago una versión separada para cada uno: local.dev.xml, htaccess-dev local.staging.xml, htaccess-staging local.production.xml, htaccess-production
... y luego hacer softlinks a ellos para cada entorno:
ln -s htaccess-dev .htaccess
cd app/etc/
ln -s local.dev.xml local.xml
y así.
Restricción de acceso a ciertos desarrolladores: no hago esto. Sin embargo, puede desarrollar una estrategia de implementación en git que permita a un administrador de versiones decidir qué entra y qué no.
Gestionar cambios en la base de datos: esa es la parte más difícil. Simplemente usamos mysqldump desde la producción, y tenemos algunos archivos listos para usar "env-setup.sql" para cada entorno. Algo como esto (sus identificaciones pueden variar):
UPDATE core_config_data SET value=''http://magento.dev/'' WHERE config_id IN (3,4);
Normalmente agrego algunas instrucciones más que cambiarán las pasarelas de pago a entornos de prueba, cambiar correos electrónicos salientes, etc. La mayoría de estos se encontrarán en core_config_data.
Recuerde que los módulos generalmente harán sus propios cambios a la base de datos, por lo que la aplicación de un módulo bien hecho generalmente se ocupa de sí misma. En cualquier caso, nunca aplique cambios no probados a prod, siempre realice "ensayos" en entornos locales y de etapas.
Puede sacar los datos de CMS (páginas y bloques estáticos) de la base de datos descargando y cargando solo las tablas cms_ * del desarrollo del entorno en el que se realizó.
¡Buena suerte!
Uso git para administrar todos mis proyectos e implementaciones de Magento. Es mucho más fácil fusionar nuevas versiones, especialmente si usa el espejo de Magento que mantengo en github. ( Espejo de GitHub Magento )
En cuanto a su pregunta específica sobre dónde se almacena la URL base en la base de datos, intente esto:
SELECT * FROM core_config_data WHERE path = "web/secure/base_url" OR path = "web/unsecure/base_url";
Utilizo las mismas mejores prácticas que cualquier aplicación web mientras desarrollo magento. También, desde el punto de vista religioso, evito hacer cambios en los archivos principales (muchos documentos en la wiki de magento le piden que modifique los archivos principales).