¿La mejor manera para implementaciones con comstackciones, administradores de dependencies y GIT?

Actualmente estoy trabajando con Git, Git Flow, Gulp y Bower. Estoy trabajando en la twig de develop y creo lanzamientos con Git Flow en la twig master . Así que el develop es igual a mi entorno local y de testing, release/version al entorno de aceptación y la twig master es igual al entorno de producción. Ver: http://nvie.com/files/Git-branching-model.pdf . En cada entorno se ejecuta Git, por lo que la implementación no es más que: Git git pull origin master .

Tengo algunas dependencies como Bootstrap y Font Awesome manejadas con Bower y estoy usando Gulp para ver files .less para "comstackr" a css, minificar css / js, etc.

Ahora hacia las preguntas: ¿qué debería estar en mi repository de Git? Digamos que estoy trabajando en un proyecto de Magento, sería excesivo poner Magento y todas las dependencies de Bower en el repository. Actualmente estoy excluyendo solo los node_modules (para Gulp) y bower_components (contiene dependencies), cuando ejecuto Gulp, los files .less de Bootstrap se "fusionarán" y "comstackrán" con mis files .less relacionados con el proyecto. El file .css "comstackdo" está actualmente incluido en mi repository, de lo contrario no es posible realizar una implementación con solo git pull . Para que funcione sin tener la versión "comstackda" en Git, tengo que ejecutar Gulp en el server de producción.

  1. ¿Cuál es el mejor método para no tener mi plataforma (Magento o WordPress) en mi repository de Git, pero mantener la posibilidad de actualizar fácilmente? Encontré esta solución: http://blog.g-design.net/post/60019471157/managing-and-deploying-wordpress-with-git donde están usando Git Submodules. Buena solución, pero de esta manera la plataforma debe estar en un subdirectory. No es ideal porque tengo que "hackear" para que funcione de esa manera (copie el index.php y cambie las routes include, etc.).

  2. ¿Qué hay de los complementos / modules? Los complementos de terceros no deberían estar en mi repository también. Solo los complementos que he creado yo mismo. Pero no todos los complementos de terceros tienen un repository de Git para usar con, por ejemplo, los submodules de Git. Para WordPress es solo un directory, por lo que en teoría es posible, pero para Magento, la mayoría de los complementos no son solo un directory (tienen files en los directorys de app/code , app/design , skin , etc.). Tengo muchos sitios de WordPress y Magento con múltiples complementos / modules que coinciden, ahora cada complemento / module está en el repository de cada sitio.

  3. ¿Deben los files "comstackdos" estar en un repository? Si me preguntas: no, pero actualmente lo estoy haciendo así que es fácil de implementar. ¿Es general tener a Bower y ejecutar Gulp en un server de producción para las dependencies y "comstackr" en el server de producción justo después de un git pull ? Continúa ejecutando un observador Gulp (como hago localmente) en la producción requiere algunos resources extra innecesarios?

Espero que alguien pueda ponerme en la dirección correcta.

Es difícil proporcionar una respuesta universal que funcione para Magento, WordPress y otras plataforms. Mi respuesta se dirige principalmente a Magento, pero estoy seguro de que conceptos similares podrían aplicarse a WordPress y otras plataforms.

  1. Es posible instalar Magento automáticamente como una dependencia usando Composer con magento-composer-installer . Puede usar un espejo público, como este , o configurar su propio repository. Una vez que haya instalado Magento como una dependencia, debería ser muy sencillo actualizarlo, al igual que cualquier otra dependencia.

  2. También puede usar Composer para modules (después de todo, Magento en sí es solo un set de modules y algunos scripts para unir todo). FireGento tiene muchos modules comunes de Magento que se pueden usar con Composer fuera de la caja. También puede configurar sus propios repositorys para usar con Composer (lo hacemos para los modules internos que usamos para múltiples sitios).

    En cuanto a los modules que no tienen sus propios repositorys, tiene tres opciones: no los use (cuantos less modules, mejor), cree sus propios repositorys, o simplemente comprométalos junto con el rest de su código base

  3. En un mundo ideal, su repository solo debe consistir en sus propios files de origen. Todo lo demás, ya sea comstackdo, instalado a través de un administrador de dependencies o creado de alguna manera de alguna manera, no debería estar en el repository.

    Pero no vivimos en un mundo ideal, es doloroso ejecutar Composer, Bower, Git, Gulp, Sass y todo lo demás que está utilizando en todos los entornos en los que desea implementar (máquinas de desarrollo, server de testing (s), server (s) de almacenamiento intermedio, server (s) de producción, etc.).

    ¿Y qué pasa si esas dependencies tienen dependencies? ¿Qué sucede si está usando un plugin de Gulp que funciona bien en uno de sus serveres, pero falla en otro? ¿Qué sucede si alguien hace una implementación y olvida ejecutar algunas de las comstackciones necesarias a través de Gulp? Por supuesto, la respuesta a estas preguntas es la testing y la automation. Debería poder hacer clic en un button (o escribir un command, para los puristas) y hacer que todo se implemente automáticamente: se emite un git pull , se ejecutan los commands gulp apropiados, y así sucesivamente. Pero a less que tenga la mano de obra y las horas para configurar un sistema tan sofisticado, no vale la pena.

En general, utilizamos una combinación de los diferentes puntos anteriores. Al final, terminamos comprometiendo (casi) todo en el repository, lo que da como resultado implementaciones tan simples como git pull o svn up . Por supuesto, los files de configuration (cnetworkingenciales, files .htaccess, etc.) no entran en el repository, ni tampoco los files de huellas dactilares (que cargamos manualmente).

Fabrizio Branca tiene una excelente publicación de blog aquí que pasa por muchos de los puntos descritos para limpiar y actualizar una configuration de Magento.