在预发布环境从代码库完整 clone 一份代码到指定路径，然后执行

composer install --prefer-dist --no-dev
composer dumpautoload --no-dev --optimize

然后通过 rsync 同步到生产环境

rsync -zr --exclude-from=${PROJECT_DIR}/.deploy/rsync.excludes ${PROJECT_DIR}/ production:${PROJECT_DIR}/

vendor 目录里有很多文件并不需要发布到生产环境，可以设置一个忽略文件列表：

.git/

app/config/local/
app/config/test/
app/config/testing/
app/config/pre-release/

app/config/packages/**/local/
app/config/packages/**/test/
app/config/packages/**/pre-release/

app/database/migrations/*
app/database/seeds/*

app/start/local.php
app/start/test.php
app/start/testing.php
app/start/pre-release.php

app/storage/cache/*
app/storage/logs/*
app/storage/sessions/*
app/storage/views/*

app/tests/*Test.php
app/tests/**/*Test.php

vendor/**/tests/
vendor/**/test/
vendor/**/Tests/
vendor/**/doc/
vendor/**/notes/
vendor/**/test-suite/
vendor/**/*.md
vendor/**/README
vendor/**/phpunit.xml.*
vendor/**/.travis.yml

phpunit.xml

为了发布速度更快一些，可以先打包，然后再 scp 到生产环境。

这些工作都可用脚本来自动完成，只需前期调试完善，后面发布就很轻松了。

直接composer。。。

composer部署便于以后升级

不上传vender，用composer install方便

1. 我觉得升级数据库用 Migrations 不靠谱。比如，表结构变了，旧数据要导入新表里，这个怎么用Migrations 实现？除了在 Migrations 写导入导出逻辑，我想不到其他方法了。但这样和自己写脚本没啥区别了吧。

2. vender 还是直接 composer 吧。它就是干这个活的。不过需要注意本地生成的 .lock 需要删除。

3. 服务器上也用 artisan/composer。