Repository deployment and Composer : what workflow?

Question

As a PHP developer I find myself working with Composer a lot. In the past it was on personal projects and such so I didn't have much problems with it, but now with Laravel 4 it's on project that require deploying and I'm in kind of a struggle to adapt my workflow.

All my projects are git repositories, thus per convention and because it's still quite buggy, like most developers I put the vendor directory in my .gitignore. Now the problem is : I also use Git to deploy to the server, and by all logic the vendor directory is not uploaded as it's not tracked by the repository.

So my question is towards people that have worked with Composer and Git for longer than me : what is the best workflow to keep the server in sync ? How to track the vendor folder without really tracking it ? I tried uploading it every time I update with Composer but some of my vendor folders are quite big and I can't manually upload 30Mb of files every time something updates.

I don't really know, how do you guys work it out ? I tried not ignoring the vendor folder but Git just messes it up, half are recognized as cloned repos and are just ignored anyway, etc.

UPDATE : Note that I'm on a shared host so I don't have access to the server's terminal.

Answer 1

You can use something like jenkins to ftp your files over this way you can direct jenkins to run composer install on the jenkins server and then ftp the files over.

This also allows you to ignore the vendor folder.

It does require a build server to be made and you would need to be able to execute commands vs the build server

Answer 2

The key is your composer.lock file. The composer.lock keeps track of exactly what packages (and versions) you have installed. When you deploy, send your composer.lock file up to the production server as well, and simply do a composer update. All the exact same package versions will be installed. With deployment software like Capistrano or Flightplan you can make the composer update step part of the process so it happens automatically.

Answer 3

This is an old question but in case anybody is looking a solution:

I slightly modify the @dave1010 answer to use git pull instead of 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

There is maybe a better solution using capistrano/composer. But I like mine better.

Answer 4

I'm working on something like this in the git post-receive hook on the server. This isn't tested and may be buggy, but you should get the idea.

#!/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

Ideally all of the deploy (i.e. in this case the git checkout and the composer install) except one single mv would happen in isolation, outside of www. This doesn't work if you have untracked files (eg CMS uploads) in your working tree and rely on PHP's __FILE__ not resolving symlinks (due to this PHP bug).

Answer 5

Capistrano (or Capifony if you are using Symfony2) is very useful for deployments with composer. You can trigger a deployment remotely and it will run a composer install in isolation so the site remains online until it has been deployed successfully. There are many other benefits such as retaining previous deployments and rolling back, copying old vendors before deployments, compiling assets etc. etc.

Answer 6

The best way is to run composer install on the server after updating to the latest code. You should also make sure you commit your composer.lock file, which the server will then use to install (you should not run composer update on the server).