使用CI/CD服务器实现生产环境自动化部署的正确方案咨询

你对tag的认知存在遗漏，tag的作用远不止记录分支快照：

• 可追溯性：生产环境出现故障时，你可以直接通过tag快速定位到对应发布版本回滚、排查问题，比匹配commit hash效率高得多，多团队协作场景下语义化的版本号tag（比如v2.3.1）的辨识度远高于随机字符串的commit id
• 合规支持：如果你的业务需要做等保、合规审计，tag是明确的生产发布版本凭证，相比随意拉取main分支发布的模式，更易满足审计留痕要求
• 发布稳定性保障：如果后续需要做灰度发布、分批发布，tag可以固定要发布的版本内容，不会出现刚好有新代码合并到main分支，导致发布版本和测试验证版本不一致的问题

你用的TeamCity+GitHub组合可以直接适配以下方案，不需要额外引入工具：

通用操作逻辑 #

两种模式可按需选择：

推送模式（更推荐） #

1. 提前在生产服务器创建专属部署账号，仅给部署目录的读写权限，禁用密码登录，仅用SSH密钥做身份验证
2. TeamCity完成测试、构建流程后，调用内置的SFTP/SSH部署步骤，直接把构建产物传输到生产服务器的指定目录，再执行对应的服务重启命令
3. 可以给生产部署加一道手动审批门槛：仅当你打了符合规则的tag后才触发部署流程，需要负责人确认后再执行推送，避免误发布

拉取模式 #

1. 在生产服务器配置定时任务或者轻量监听进程，定期检测是否有新的生产版本tag推送
2. 检测到新版本后，自动拉取对应代码/构建产物，本地执行更新、重启操作

对应技术栈适配方案 #

• ReactJS：TeamCity执行构建生成build目录后，直接通过SFTP传到生产服务器的Nginx/Apache静态资源目录即可，传输完成可以追加一步清除CDN缓存的脚本
• Laravel：推送除了vendor、.env、storage之外的代码到生产目录，推送完成后在服务器执行composer install --optimize-autoloader --no-dev、php artisan config:cache、php artisan route:cache、php artisan migrate --force命令即可，生产环境的.env提前配置好，部署时设置过滤规则不覆盖该文件
• C# .NET Core：TeamCity执行dotnet publish -c Release得到发布包，传到生产服务器后停止对应IIS站点/Systemd服务，覆盖文件后重启服务即可

直接通过TeamCity的分支触发规则就能实现，步骤如下：

1. 在TeamCity中分别创建三套部署配置，对应dev、staging、prod三个环境，每套配置单独关联对应的部署目标服务器、环境变量、执行脚本
2. 给每套部署配置设置对应的触发规则：
   • dev环境部署配置：仅监听dev分支的代码提交，只要有代码合并到dev分支，自动触发测试、构建、部署到开发环境
   • staging环境部署配置：仅监听staging分支的代码提交，特性分支合并到staging后，自动触发构建部署到预发布环境
   • prod环境部署配置：仅监听main分支的合并操作，或者仅监听v*格式的tag推送，触发后先进入手动审批队列，确认后再推送到生产环境
3. 不同环境的配置不要硬编码在代码里，通过TeamCity的环境变量功能注入，或者在对应服务器本地存储配置文件，部署时设置过滤规则不覆盖即可

内容的提问来源于stack exchange，提问作者Boardy