Despliegue de repository y Compositor: ¿qué flujo de trabajo?

Como desarrollador de PHP, me encuentro trabajando mucho con Composer. En el pasado, se trataba de proyectos personales, por lo que no tuve muchos problemas, pero ahora con Laravel 4 es un proyecto que requiere implementación y estoy en una especie de lucha para adaptar mi flujo de trabajo.

Todos mis proyectos son repositorys de git, por convención y porque todavía tiene errores, como la mayoría de los desarrolladores, puse el directory de vendor en mi .gitignore . Ahora el problema es: también uso Git para implementarlo en el server, y por lógica, el directory del proveedor no se carga ya que el repository no lo rastrea.

Así que mi pregunta es hacia las personas que han trabajado con Composer y Git por más time que yo: ¿cuál es el mejor flujo de trabajo para mantener el server sincronizado? ¿Cómo rastrear la carpeta del proveedor sin realmente rastrearla? Intenté uploadlo cada vez que actualicé con Composer, pero algunas de las carpetas de mi proveedor son bastante grandes y no puedo cargar manualmente 30 MB de files cada vez que algo se actualiza.

Realmente no sé, ¿cómo lo resuelven? Traté de no ignorar la carpeta del vendor pero Git simplemente lo estropea, la mitad son reconocidos como repositorys clónicos y simplemente se ignoran de todos modos, etc.

ACTUALIZACIÓN: tenga en count que estoy en un host compartido, por lo que no tengo acceso a la terminal del server.

La mejor manera es ejecutar la composer install en el server después de actualizar al último código. También debe asegurarse de confirmar su file composer.lock, que el server utilizará para instalar (no debe ejecutar la composer update en el server).

Capistrano (o Capifony si está utilizando Symfony2) es muy útil para implementaciones con compositor. Puede desencadenar una implementación de forma remota y ejecutará una installation de compositor de forma aislada para que el sitio permanezca en línea hasta que se haya desplegado correctamente. Hay muchos otros beneficios, como conservar implementaciones previas y retroceder, copyr proveedores antiguos antes de las implementaciones, comstackr activos, etc.

Estoy trabajando en algo así en el gancho de git post-receive en el server. Esto no está probado y puede tener errores, pero debe entenderse.

 #!/bin/bash # get the updated composer.json git checkout master -- composer.json # only do this stuff if composer.json is different # you could check this manually, or with git or cmp cp composer.json tmp/composer.json # may take a minute, but won't take the site down (cd tmp; composer install --prefer-dist) # this doesn't seem to be atomic git checkout -f # switch vendors over # this isn't quite an atomic operation, but is very close # you could probably do it with symlinks and "mv -Tf" to make it atomic mv vendor vendor.old mv tmp/vendor vendor rm -r tmp vendor.old 

Idealmente, todo el deployment (es decir, en este caso, la installation de git checkout y la composer install del composer install ), excepto un solo mv , ocurriría aislado, fuera de www . Esto no funciona si tiene files sin seguimiento (por ejemplo, cargas CMS) en su tree de trabajo y confía en que __FILE__ de PHP no resuelve los enlaces simbólicos (debido a este error de PHP ).

Esta es una vieja pregunta, pero en caso de que alguien busque una solución:

Modifico ligeramente la respuesta @ dave1010 para usar git pull lugar de git checkout--force

 #!/bin/bash # get only composer files git fetch git checkout origin/master -- composer.json git checkout origin/master -- composer.lock # make sure tmp is empty rm -rf tmp mkdir tmp # copy the composer files to tmp cp -r vendor tmp/vendor cp composer.json tmp/composer.json cp composer.lock tmp/composer.lock # may take a minute, but won't take the site down (cd tmp; composer install --no-scripts --verbose; cd ..) # switch vendors over rm -rf vendor_old mv vendor vendor_old mv tmp/vendor vendor # update your code git pull # run again composer install. This time will print 'Nothing to install or update' # but will execute pre/post scripts & generate autoload files composer install --optimize-autoloader 

Tal vez haya una mejor solución usando capistrano / compositor . Pero me gusta el mío mejor.

Puedes usar algo como jenkins para convertir tus files de esta forma. Puedes indicarle a jenkins que ejecute la installation del compositor en el server jenkins y luego volcar los files.

Esto también le permite ignorar la carpeta del vendedor.

Requiere que se realice un server de compilation y usted necesitaría poder ejecutar commands frente al server de compilation.

La key es tu file composer.lock . El composer.lock realiza un seguimiento de exactamente qué packages (y versiones) ha instalado. Cuando implemente, envíe su file composer.lock al server de producción también, y simplemente haga una composer update . Se instalarán todas las mismas versiones exactas del package. Con el software de implementación como Capistrano o Flightplan puede hacer que el paso de composer update del composer update parte del process para que ocurra automáticamente.