Mi proceso generalmente se gestiona alrededor de un repositorio de control de origen (SVN en mi caso), lo que hace las cosas mucho más fáciles (o posibles, realmente ...). La idea es mantener todo lo posible en el repositorio y usar las actualizaciones y etiquetas SVN para publicar los cambios.
local.xml: me muevo este archivo en SVN para local.xml.dist e ignorar el archivo real local.xml en el repositorio. Esto le permite usar diferentes credenciales de base de datos y hosts en sus instalaciones sin contaminar la base de código.
otros ignora: Consulte this question para obtener más archivos que deben ignorarse en la base de datos. Básicamente, cualquier elemento exclusivo del entorno debe mantenerse fuera del control de la versión y manejarse en el host real. Sus archivos .htaccess serán relevantes aquí.
configuración de host: mi entorno de ensayo y entornos dev están configurados para ejecutarse fuera de/trunk desde el repositorio. El desarrollo ocurre aquí, y puede ser llevado al escenario periódicamente (o bajo demanda) a través del svn up para mostrar nuevas características al cliente y hacer UAT. Sin embargo, el entorno de producción necesita cierta protección del Salvaje Oeste del tronco, por lo que el entorno se escapa de las etiquetas. Cada vez que un conjunto de características está listo para salir, creo una etiqueta nueva desde el tronco y hago un svn switch para moverme al nuevo conjunto de códigos. Hacer las cosas de esta manera también me permite deshacer fácilmente la producción (volver a la última etiqueta). Por lo tanto, eliminé todos los archivos manuales de mi vida, lo cual es bueno.
Un sistema aún mejor (que no he necesitado aún) sería usar svn export para crear una copia completa del árbol de códigos en el sistema de producción, y usar ln para cambiar entre ellos. Algo como esto:
> cd /home/apacheuser
> ls -l
www -> /home/apacheuser/tag_1.0.1
tag_1.0.1
> svn export /url/for/repo/tags/1.0.2 tag_1.0.2
... svn exports here ...
> rm www; ln -s /home/apacheuser/tag_1.0.2 www
De esta manera, los cambios de versión son instantáneos.
db sync volver de la producción: Para permitirme trabajar en datos ish de producción, tengo un cron-job configurado para volcar la base de datos de producción e importarla a la etapa de transición. Mientras esto sucede, el script eliminará los datos sensibles de los clientes (y cambiará las direcciones de correo electrónico de los clientes para que todos los correos electrónicos lleguen a mí). También cambiará la configuración de la puerta de enlace de la tarjeta de crédito a una puerta de enlace de prueba y cambiará los parámetros base_url para que las URL del sitio de ensayo funcionen correctamente.
desarrollo nuevo: Puede observar aquí que diferentes entornos se ejecutan aproximadamente en la misma base de código (menos cualquier cambio nuevo), lo que puede parecerle problemático por lo que ha notado sobre cambios en la base de datos, etc.
La única forma de gestionar esta complejidad (¡y de la manera correcta, al mismo tiempo!) Es asegurarse de que el código en sí mismo realiza un seguimiento de los cambios necesarios en el entorno. Magento admite actualizaciones automáticas de versiones de módulos, incluidos scripts de bases de datos, que debe usar para realizar cambios de esquema, etc. Esto significa que, al implementar un nuevo código en etapas/producción (o cuando lo obtiene de otro desarrollador en su entorno de desarrollo), todos los parches de base de datos se aplican automáticamente.
Esto también significa que debe escribir una nueva funcionalidad para que sea lo menos destructiva posible. Los temas de Magento, los módulos desactivados y otros pueden usarse para hacer esto realidad. Por ejemplo, al crear un nuevo tema para el sitio, asegúrese de no modificar el comportamiento del núcleo y mantener todos los activos nuevos en un tema que será inerte en la producción hasta que se implemente.
más desarrolladores: Esta configuración se basa en un número relativamente pequeño de desarrolladores en un proyecto. Existe una suposición implícita de que, cuando desea etiquetar una nueva versión, puede hacer que la troncal entre en un estado operativo para hacerlo. Con más desarrolladores, este será el caso cada vez menos, por lo que es necesaria una configuración de repo más compleja. Si me encuentro con eso, mi plan es pasar a usar git en lugar de SVN y usar ramas de características para nuevos desarrollos.
Avísame si algo de eso no estaba claro. ¡Espero que ayude!
Gracias, Joe
estoy interesado en esto también. Mi trabajo principal es mantener una tienda de comercio electrónico basada en .NET, donde utilizamos Windows Installer para implementar actualizaciones de forma controlada, y los proyectos secundarios de Magento son un poco nuevos, ¡y nos sentimos un poco temerarios en lo que respecta a la implementación! Creo que uno de estos días, voy a tener que construir un gran script bash para administrar el proceso de actualización. –