Mejores prácticas para Magento Deployment

Question

Estoy buscando configurar un proceso de implementación para un sitio altamente personalizado de Magento, 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 puede solicitar actualizaciones de Magento? (Individualmente en cada entorno, o en desarrollo y luego desplegar, o simplemente darse por vencido en las actualizaciones?)
• Lo que los archivos/carpetas dejan solos en cada entorno (por ejemplo, magento/app/etc/local.xml)
• Do ¿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 gestionas los cambios en la base de datos?

---

diseñador de temas de archivos/carpetas

Los diseñadores pueden restringido a la edición de la siguiente folders-

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/ 

---

Extensión Desarrollador de archivos/carpetas

desarrolladores de extensiones que se pueden editar las siguientes carpetas/Files-

/app/code/local 
/app/etc/modules/<Namespace>_<Module>.xml 

---

gestión del medio ambiente Base de datos

Como URL base de la tienda se almacena en la base de datos, no se puede simplemente copiar bases de datos entre entornos. Las opciones incluyen:

• Anulación de la URL base en php. Blog article on setting up dev and staging databases
• Cambiar la URL base en la base de datos después de copiar. (¿Dónde está esto almacenado?)
• Realizando un MySQLDump o copia de seguridad, luego haciendo un reemplazo en la URL en el archivo SQL.

Answer 1

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).

Answer 2

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.(GitHub Magento Mirror)

En cuanto a usted pregunta específica acerca de dónde la URL base se almacena en la base de datos, intente esto:

SELECT * FROM core_config_data WHERE path = "web/secure/base_url" OR path = "web/unsecure/base_url"; 

Answer 3

Puede evitar el DB-manipulación (en alemán): http://blog.tudock.de/startseite/beitrag/2010/09/17/deployment-prozess-eines-magento-shops.html

Answer 4

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: Haga esto en dev. 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 aplicación/etc/local.xml. Hago una versión separada para cada uno: local.dev.xml, htaccess-dev local.staging.xml, htaccess puesta en escena local.production.xml, htaccess-producción

... y luego hacer enlaces simbólicos a para cada entorno:

ln -s htaccess-dev .htaccess 
cd app/etc/ 
ln -s local.dev.xml local.xml 

y así sucesivamente.

Restringir el 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.

Gestión de cambios en la base de datos: Esa es la parte más complicada. Simplemente usamos mysqldump desde la producción, y tenemos algunos archivos listos para usar "env-setup.sql" para cada entorno. Algo como esto (los números de identificación puede variar):

UPDATE core_config_data SET value='http://magento.dev/' WHERE config_id IN (3,4); 

Yo suelo añadir algunos más instrucciones que cambiarán pasarelas de pago a entornos de prueba, cambiar los correos electrónicos salientes, etc. La mayoría de estos se encuentran en core_config_data.

Recuerde que los módulos generalmente harán sus propios cambios en 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 CMS (páginas y bloques estáticos) de la base de datos descargando y cargando solo las tablas cms_ * desde cualquier entorno en que se haya realizado el desarrollo.

¡Buena suerte!

Answer 5

Después de mucho ensayo y error, hemos llegado con un flujo de trabajo que se adapte a nosotros también:

http://www.dhmedia.com.au/blog/perfect-magento-workflow-using-git

incluye la gestión de base de datos, todo el código bajo control de origen (con Git), despliegues, escenarios y sitios de desarrollo, desarrolladores múltiples, entornos múltiples, etc ...

Espero que esto ayude a alguien!