前端 CI/CD 实践：构建与自动化部署详解

关于 CI/CD 的冷思考

CI/CD 听起来像是为了显得专业而搞的一套复杂流程？别天真了。你以为配置了就能解决所有问题？实际上，配置出错的概率有时比手动部署还高。不同的工具坑也不同，比如 Jenkins 的配置文件对新手来说就像天书，GitLab CI 的 YAML 语法也能让人崩溃。

为什么要做自动化

在真实的项目中，我们更看重实际收益：

1. 提升效率：自动完成代码测试、构建和部署，减少重复劳动。
2. 降低风险：避免手动操作失误，提高部署可靠性。
3. 快速反馈：提交后立即触发测试，尽早发现问题。
4. 环境一致：确保开发、测试、生产环境的配置差异最小化。

手动部署的痛点

回顾一下典型的手工流程：

# 1. 手动运行测试
npm test
# 2. 手动构建项目
npm run build
# 3. 手动上传构建文件到服务器
scp -r build/* user@server:/var/www/html/
# 4. 手动重启服务
ssh user@server "sudo systemctl restart nginx"

这种方式的隐患很明显：容易忘记步骤、过程不透明、环境配置不一致导致失败，且无法快速回滚。随着项目复杂度上升，维护成本会急剧增加。

主流工具链配置

GitHub Actions

这是目前最流行的选择之一，配置相对简洁。

# .github/workflows/deploy.yml
name: Deploy to Production
on:
  push:
    branches: [ main ]
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '16'
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
      - name: Build project
        run: npm run build
      - name: Deploy to server
        uses: easingthemes/ssh-deploy@v2
        with:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          ARGS: '-rltgoDzvO --delete'
          SOURCE: 'build/'
          REMOTE_HOST: ${{ secrets.REMOTE_HOST }}
          REMOTE_USER: ${{ secrets.REMOTE_USER }}
          TARGET: ${{ secrets.REMOTE_TARGET }}
      - name: Restart server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.REMOTE_HOST }}
          username: ${{ secrets.REMOTE_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: sudo systemctl restart nginx

注意这里使用了 Secrets 来管理密钥，千万不要硬编码在仓库里。

GitLab CI

如果你使用 GitLab，其内置的 CI/CD 功能非常强大。

# .gitlab-ci.yml
stages:
  - test
  - build
  - deploy

test:
  stage: test
  image: node:16
  script:
    - npm install
    - npm test
  only:
    - main

build:
  stage: build
  image: node:16
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - build/
  only:
    - main

deploy:
  stage: deploy
  image: alpine:latest
  script:
    - apk add --no-cache rsync openssh
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - ssh-keyscan -H $REMOTE_HOST >> ~/.ssh/known_hosts
    - rsync -avz --delete build/ $REMOTE_USER@$REMOTE_HOST:$REMOTE_TARGET
    - ssh $REMOTE_USER@$REMOTE_HOST "sudo systemctl restart nginx"
  only:
    - main
  environment:
    name: production

这里通过 Alpine 镜像减小体积，并手动处理 SSH 密钥权限，适合对资源敏感的场景。

Jenkins Pipeline

对于企业级复杂需求，Jenkins 依然是主力。

// Jenkinsfile
pipeline {
  agent any
  stages {
    stage('Checkout') {
      steps {
        checkout scm
      }
    }
    stage('Install Dependencies') {
      steps {
        sh 'npm install'
      }
    }
    stage('Test') {
      steps {
        sh 'npm test'
      }
    }
    stage('Build') {
      steps {
        sh 'npm run build'
      }
    }
    stage('Deploy') {
      steps {
        sh '''
          scp -r build/* user@server:/var/www/html/
          ssh user@server "sudo systemctl restart nginx"
        '''
      }
    }
  }
  post {
    always { echo 'Pipeline completed' }
    success { echo 'Deployment successful' }
    failure { echo 'Deployment failed' }
  }
}

Groovy 脚本提供了极强的灵活性，但学习曲线也相对陡峭。

环境变量管理

敏感信息请统一放入 .env 或平台提供的 Secret 管理中，切勿提交到版本控制。

# .env
REMOTE_HOST=your-server.com
REMOTE_USER=deploy
REMOTE_TARGET=/var/www/html/
# SSH_PRIVATE_KEY 请在 CI/CD 平台的 Secrets 中配置，不要明文存储

核心原则

CI/CD 确实能提效，但我见过太多开发者滥用它，反而让流程变得臃肿。花几小时调试 CI 配置却不如手动部署快，这种情况并不少见。

有些流程过度设计，包含大量无关测试，拖慢了部署速度。记住，自动化的目的是提高效率，不是为了炫技。如果配置导致部署变慢或不可靠，那就是失败的。

对于大型项目，CI/CD 是必须的；但对于小型项目，过度的配置只会增加维护成本。把握尺度，按需配置，才是正道。