前端CI/CD流程：自动化部署的正确打开方式
前端CI/CD流程：自动化部署的正确打开方式
毒舌时刻
CI/CD？听起来就像是前端工程师为了显得自己很专业而特意搞的一套复杂流程。你以为配置了CI/CD就能解决所有部署问题？别做梦了！到时候你会发现，CI/CD配置出错的概率比手动部署还高。
你以为随便找个CI/CD工具就能用？别天真了！不同的工具配置方式不同，坑也不同。比如Jenkins的配置文件就像是天书，GitLab CI的YAML语法也能让你崩溃。
为什么你需要这个
- 自动化部署：CI/CD可以自动完成代码测试、构建和部署，减少手动操作，提高部署效率。
- 减少人为错误：自动化部署可以避免手动部署时的人为错误，提高部署的可靠性。
- 快速反馈：CI/CD可以在代码提交后立即进行测试和构建，及时发现问题，提供快速反馈。
- 持续集成：CI/CD可以确保代码的持续集成，避免代码冲突和集成问题。
- 环境一致性：CI/CD可以确保不同环境的配置一致，避免环境差异导致的问题。
反面教材
# 这是一个典型的手动部署流程 # 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 GitLab CI配置
# .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 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' } } } 环境变量配置
# .env # 服务器配置 REMOTE_HOST=your-server.com REMOTE_USER=deploy REMOTE_TARGET=/var/www/html/ # SSH密钥（在CI/CD平台的secrets中配置） # SSH_PRIVATE_KEY=your-ssh-private-key 毒舌点评
CI/CD确实能提高部署效率，但我见过太多开发者滥用这个特性，导致部署流程变得更加复杂。
想象一下，当你花了几个小时配置CI/CD，结果发现部署失败了，你需要调试CI/CD配置，这比手动部署还麻烦。
还有那些过度配置的CI/CD流程，包含了太多不必要的步骤，导致部署时间变得很长。比如每次部署都要运行所有测试，包括那些与当前修改无关的测试。
所以，在使用CI/CD时，一定要把握好度。不要为了自动化而自动化，要根据实际情况来决定CI/CD的配置。
当然，对于大型项目来说，CI/CD是必不可少的。但对于小型项目，过度的CI/CD反而会增加开发成本和维护难度。
最后，记住一句话：CI/CD的目的是为了提高部署效率和可靠性，而不是为了炫技。如果你的CI/CD配置导致部署变得更慢或更不可靠，那你就失败了。
