没有上docker，单服务器持续集成/发布应该怎么做？

如果我使用代码更新，然后手动去服务器上 git pull 会更好更快吗？ :joy: 这就是最优解. 其他的没意义.

两台服务器那个就好办了。如果是需要编译的语言，那就手动去pull，然后执行编译后部署。如果是不需要编译的语言，在测试服务器那就写个钩子（或者有现成的工具同步代码），只要代码提交就同步。

如果是生产环境，那还是需要手动去做，测试服务器可以瞎折腾，但是生产环境还是人去干预比较保险。至于怎么在代码更新的时候保证可用，那就是工作流程的问题了，比如可以设置一个开关或者配置，所有的请求都跳转到维护页面，然后去更新，或者选择用户较少的时候直接更新。

我们之前 采用sync的时候，是在访问低谷期的时候，把 nginx 关闭的，然后 sync 过去代码，再启动 nginx。后来采用docker以后依然是 关闭服务，再更新，启动服务。目前2台服务 没有办法做到 蓝 绿 部署， 可以采用k8s 全自动

2 台服务器， 手动 + git (自建或 gieee) 部署

deployer 了解一下

最简单的方法 写个shell脚本来检查Git仓库是否有新的提交，如果有，则执行git pull命令来更新

php-fpm 的话本身就是热更新，除非你改配置需要重启 php-fpm。我们10多年前都用 rsync 更新多台服务器代码的。

切root目录我没明白楼主想怎么搞，传统集群的搞法是两台服务器，新服务器更新并启动后通过负载均衡将流量切过去。只不过这个过程现在被k8s容器化了。

老项目部署流程改造可以看看团队有没有预算，我最近也在思考这类问题，如果不能将项目隐藏的运维成本显现出来，老板总以为功能上线后运维不花钱似的。

我之前是 Gitlab CI/CD + Deployer 的方案，可以参考我的这篇博客《DevOps 之 Laravel 基于分支的多环境部署》。

测试环境不需要多分支的话删除对应的配置即可！

我个人用webhook

基于楼主现有机制（文件发布）的话，vendor 目录是如何处理的

1、是否先构建完，再把构建完成的文件进行“包发布”会更合理？

2、关于新旧版本的问题，是不是可以直接在生产服务器保留多个版本（通过目录区分），通过 linux 软链切换版本与回滚

要想停机影响的时间尽可能缩短，应该使用OP的第三个方案（蓝绿发布）

虽然是单机，但是分2个目录，另外一个目录把composer对应的包安装完、缓存之类的处理好之后

再将Nginx解析到这个目录，nginx -s reload 即可

当然这个过程，可以是人工手动的，也可以借助CI/CD工具

当前你们的解决方案已经足够满足要求了

1. 确认 opcache 是否开启，没开的话生产环境可以开一下，更新代码后重启 php-fpm 或手动重置 opcache 缓存 即可更新代码
2. Jenkins 这类工具就是为了避免你老去登录服务器的操作的，如果你不在乎，可以手动执行更新
3. 一般单机情况下直接更新即可，不需要考虑那么多，如果更新内容确实庞大，可考虑暂停服务，设置维护时间，在维护时间内处理好数据库的备份、更新，代码的更新等操作内容

单台服务器 很简单的散 webhook + 绿蓝部署 自己写个脚本就行了

jenkins + 部署脚本就完全够用，即便是集群也完全够用。部署脚本其实没什么难度，只是需要你对git+linux命令要熟悉，我之前写过自动打包(支持全量和增量)+部署+回滚，关键是你要手撸一遍，如果不想写，也可以用这个工具。

博客：简单轻松部署你的项目 - Deployer

直接钩子

原有容器不变的情况下，用新代码起个容器，队列、迁移等执行完成后，停用原来的容器

话说fpm是不是本身就支持平滑重启的