前端CI/CD流程：自动化部署的正确打开方式 毒舌时刻 CI/CD？听起来就像是前端工程师为了显得自己很专业而特意搞的一套复杂流程。你以为配置了CI/CD就能解决所有部署问题？别做梦了！到时候你会发现，CI/CD配置出错的概率比手动部署还高。 你以为随便找个CI/CD工具就能用？别天真了！不同的工具配置方式不同，坑也不同。比如Jenkins的配置文件就像是天书，GitLab CI的YAML语法也能…
CI/CD？听起来就像是前端工程师为了显得自己很专业而特意搞的一套复杂流程。你以为配置了CI/CD就能解决所有部署问题？别做梦了！到时候你会发现，CI/CD配置出错的概率比手动部署还高。
你以为随便找个CI/CD工具就能用？别天真了！不同的工具配置方式不同，坑也不同。比如Jenkins的配置文件就像是天书，GitLab CI的YAML语法也能让你崩溃。
# 这是一个典型的手动部署流程 # 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/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.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
// 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配置导致部署变得更慢或更不可靠，那你就失败了。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML 转 Markdown 互为补充。 在线工具，Markdown 转 HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML 转 Markdown在线工具，online
通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online