探讨了前端 CI/CD 流程的必要性，分析了手动部署的潜在风险，并详细展示了 GitHub Actions、GitLab CI 及 Jenkins 的配置方案。文章强调自动化测试与构建能提升效率与可靠性，同时建议根据项目规模合理配置，避免过度复杂化。
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
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online