服务器上，数据库是依赖 migrations，还是直接导sql，还是自己写install。
vender 的是在服务器上也用 composer 还是手动传？
服务器上也用 artisan/composer 吗?
其他注意事项有什么？
回复内容： 服务器上，数据库是依赖 migrations，还是直接导sql，还是自己写install。
vender 的是在服务器上也用 composer 还是手动传？
服务器上也用 artisan/composer 吗?
其他注意事项有什么？
在预发布环境从代码库完整 clone 一份代码到指定路径，然后执行
composer install --prefer-dist --no-devcomposer 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.phpapp/start/test.phpapp/start/testing.phpapp/start/pre-release.phpapp/storage/cache/*app/storage/logs/*app/storage/sessions/*app/storage/views/*app/tests/*test.phpapp/tests/**/*test.phpvendor/**/tests/vendor/**/test/vendor/**/tests/vendor/**/doc/vendor/**/notes/vendor/**/test-suite/vendor/**/*.mdvendor/**/readmevendor/**/phpunit.xml.*vendor/**/.travis.ymlphpunit.xml
为了发布速度更快一些，可以先打包，然后再 scp 到生产环境。
这些工作都可用脚本来自动完成，只需前期调试完善，后面发布就很轻松了。
直接composer。。。
composer部署便于以后升级
不上传vender，用composer install方便
我觉得升级数据库用 migrations 不靠谱。比如，表结构变了，旧数据要导入新表里，这个怎么用migrations 实现？除了在 migrations 写导入导出逻辑，我想不到其他方法了。但这样和自己写脚本没啥区别了吧。
vender 还是直接 composer 吧。它就是干这个活的。不过需要注意本地生成的 .lock 需要删除。
服务器上也用 artisan/composer。