Proceso de flujo de trabajo de Magento con git

He estado codificando sitios de Magento usando trabajos cron para manejar copys de security, pero se vuelve un poco torpe cuando trato de volver a las versiones anteriores del sitio. Básicamente, tengo que profundizar en las copys de security y revertir manualmente las cosas. He leído sobre git y me gusta la idea de poder documentar mis cambios a través del ciclo de desarrollo y volver a solo las cosas específicas que cambio con unos pocos commands.

Actualmente tengo dos sucursales en mi repository local (master, develop). En esencia, hago todo mi desarrollo en la twig de desarrollo y fusiono todo en la twig principal cuando termino con un set específico de tareas y hago upload las cosas a mi repository de gitbucket con fines de respaldo y solo para entrar en el habito de usar una repository remoto

Soy nuevo en git, ¿este sonido es suficiente para mi escenario o alguien puede recomendar un buen process de flujo de trabajo para una tienda one man usando git con Magento? Gracias.

Usamos el model de GitFlow para nuestro desarrollo de Magento. Es similar a la tuya pero con una sucursal adicional para un sitio de ensayo. Las tareas / correcciones de desarrollo más grandes también se completan en twigs separadas para garantizar que el desarrollo siempre sea razonablemente estable. Nuestros sitios de ensayo son un repository git con la twig de etapas revisada y los sitios de producción tienen la twig principal extraída. Cuando estamos listos para implementar cambios en la puesta en escena, los fusionamos para realizar una puesta en escena en nuestras máquinas locales, y enviamos a un repository de git central, luego activamos el server. Funciona bien, pero debe tener cuidado con la aplicación / etc / local.xml, ya que esto debería ser diferente en cada entorno. También querrás asegurarte de que cosas como los medios y las carpetas var no terminen en tu git repo.

Github publica un .gitignore para Magento, pero el problema que tengo es que excluye todos los files core de Magento. Terminas con un buen repository limpio que contiene solo tus cambios, pero no algo que se puede implementar. Usamos un .gitignore mucho más simple que básicamente solo excluye los medios var y app / etc / local.xml. Generalmente usamos un solo control remoto (por ejemplo, Github) y lo implementamos desde allí.

En los serveres en los que estamos implementando, generalmente tenemos acceso de shell y git instalados, por lo que la implementación es una cuestión de ssh'ing y ejecutar un git pull (o search y fusionar) desde el control remoto normal.

Mantenemos los sitios de ensayo como una twig separada en git, y los implementamos de la misma manera. Entonces, nuestro process se ve como Desarrollar en la twig de características y fusionarse en "desarrollar" cuando termina. Cuando la testing de integración esté completa, combine el "desarrollo" (o los cambios selectivos) con la "puesta en escena" y la implementación. Cuando esté listo para la producción, combine "puesta en escena" (o selección individual de cambios) en la twig "principal". Esto es básicamente GitFlow, pero la twig de "preparación para la liberación" es de larga duración.

Como señala el tutorial de Sonassi en los comentarios, el problema con los medios de enlace simbólico es que si eliminas un file de medios de la producción, obtienes un enlace roto en la etapa y viceversa. En lugar de vincular los dos, actualizamos el código de transición de git, pero ejecutamos los sitios de producción y producción por separado. Si necesitamos nuevos datos en la etapa, por cualquier razón, tomaremos una copy de los medios de producción y la database y los restauraremos en el sitio de ensayo.

El model de Gitflow utiliza numbers de versión para las tags de lanzamiento, si tiene numbers de versión con los que el equipo astring lanzarlos, úselos. De lo contrario, si tiene algún tipo de plan de hito o sistema de sprint al que está trabajando y puede identificar un lanzamiento de esa manera, eso también funcionaría. Si todo lo demás falla, usamos la date / hora en que ocurrió la implementación. p.ej

git tag -a deployed-`date +%Y%m%d-%H%M` -m "Code release at `date`"