从前端代码提交到自动部署上线的完整实践流程分享

我的写法，亲测靠谱

先说说我用自动部署的实战经验吧。这几年做项目，自动部署真成了我的好帮手，特别是处理频繁更新的项目时。我一般会用 GitHub Actions 来做自动部署，代码一推送到仓库，服务器那边就自动完成了更新。

这是我的核心配置文件，基本能覆盖大部分场景：

name: Deploy to Server

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '16'

    - name: Install dependencies
      run: npm install

    - name: Build project
      run: npm run build

    - name: Deploy to server
      uses: appleboy/scp-action@master
      with:
        host: ${{ secrets.SERVER_HOST }}
        username: ${{ secrets.SERVER_USER }}
        key: ${{ secrets.SSH_PRIVATE_KEY }}
        source: "dist/*"
        target: "/var/www/my-app"

这个配置简单易懂：监听 main 分支的推送事件，执行依赖安装、构建和部署操作。我喜欢用 appleboy/scp-action 这个插件，因为它够轻量，传输文件的速度也快。这里有几个关键点要注意：

• SSH密钥管理：不要直接写在配置里，要用GitHub的Secrets功能来保存敏感信息。
• 分支控制：只对特定分支（比如main）触发部署，避免测试分支污染生产环境。
• 构建产物路径：source字段要明确指定哪些文件需要传输，别一股脑全传过去。

这几种错误写法，别再踩坑了

说实话，我在刚开始用自动部署的时候踩了不少坑，下面这些错误写法你可千万别学。

第一种常见错误是忽略环境变量的隔离。有人喜欢这样写：

- name: Set env
  run: |
    export API_URL=https://jztheme.com/api
    npm run build

这种写法看着没问题，但实际运行时你会发现环境变量根本没生效。因为每个step都是独立的shell会话，上一个step设置的变量不会带到下一个step去。正确的做法是用workflow自带的env配置：

env:
  API_URL: https://jztheme.com/api

jobs:
  deploy:
    steps:
    - name: Build project
      run: npm run build

第二种错误是滥用通配符。有人为了省事，在scp-action里这么写：

with:
  source: "*"
  target: "/var/www/my-app"

这种写法会导致把node_modules、.git这些不必要的目录全都传到服务器上，不仅浪费时间，还可能暴露敏感信息。应该明确指定需要传输的目录或文件。

第三种错误是硬编码敏感信息。有人直接把SSH密钥写在配置文件里：

with:
  key: "-----BEGIN RSA PRIVATE KEY-----..."

这种写法太危险了，一旦代码泄露，服务器就完蛋了。一定要用GitHub Secrets来管理敏感信息。

实际项目中的坑

除了上面那些明显的错误写法，还有一些细节问题特别容易被忽视。

第一个坑是缓存问题。有时候部署完发现页面还是老样子，折腾了半天才发现是浏览器缓存或者CDN缓存的问题。我现在的做法是在HTML文件里加个版本号：

<link rel="stylesheet" href="/static/css/style.css?v=20231001">

每次部署时更新这个版本号，就能确保用户访问的是最新资源。

第二个坑是权限问题。有次部署完发现网站打不开了，检查日志才发现是文件权限不对。后来我在部署脚本里加了权限设置：

- name: Fix permissions
  run: |
    sudo chown -R www-data:www-data /var/www/my-app
    sudo chmod -R 755 /var/www/my-app

第三个坑是并发部署冲突。如果多人同时提交代码，可能会导致部署任务互相干扰。解决方法是限制并发：

concurrency:
  group: deployment
  cancel-in-progress: true

一些额外的小技巧

在实际项目中，我还总结了一些小技巧，虽然不是必须的，但用起来确实方便。

比如部署完成后发个通知，这样团队成员都能及时知道部署状态：

- name: Notify Slack
  if: always()
  uses: rtCamp/action-slack-notify@v2
  with:
    status: ${{ job.status }}
    webhook_url: ${{ secrets.SLACK_WEBHOOK }}

还有就是添加回滚机制，万一新版本有问题，可以快速回退到上一个版本：

- name: Backup previous version
  run: |
    mv /var/www/my-app /var/www/my-app-backup

最后总结一下

以上是我总结的最佳实践，主要思路就是保持简单可靠，同时注意安全性和效率。自动部署其实没有想象中那么复杂，只要避开那些常见的坑，基本都能顺利跑起来。

当然，每个项目都有自己的特点，这套方案可能还需要根据实际情况调整。比如有些项目需要用Docker部署，有些需要更复杂的多环境配置。不过万变不离其宗，核心思想都差不多。

有更好的方案欢迎评论区交流，或者你有什么疑问也可以留言，我们一起讨论。