DevOps CI/CD流水线最佳实践：从Git提交到生产部署的10分钟之旅

DevOps CI/CD流水线最佳实践从Git提交到生产部署的10分钟之旅大家好我是迪哥。从前我们部署上线要半天打包、上传、解压、重启还要提工单等审批。现在代码提交后10分钟内自动部署到生产出错还能自动回滚。这就是 CI/CD 的魔力。今天就聊聊我们用 GitHub Actions 搭的这套流水线。为什么要 CI/CD痛点前 CI/CD 时代❌ 部署慢半天一次❌ 容易错人工操作容易手滑❌ 回滚难出问题要手动恢复❌ 质量差合并代码就挂收益后 CI/CD 时代✅ 部署快提交即部署✅ 质量好代码先过测试✅ 回滚易一键回滚✅ 效率高解放运维专注开发流水线设计┌─────────────────────────────────────────────────────────────────┐ │ 开发者 Git Push 代码 │ └─────────────────────────┬───────────────────────────────────────┘ │ ┌──────▼────────┐ │ 1. 代码扫描 │ (SonarQube) └──────┬────────┘ │ ┌──────▼────────┐ │ 2. 单元测试 │ (JUnit) └──────┬────────┘ │ ┌──────▼────────┐ │ 3. 构建镜像 │ (Docker Build) └──────┬────────┘ │ ┌──────▼────────┐ │ 4. 推镜像仓库 │ (Harbor/ACR) └──────┬────────┘ │ ┌──────▼────────┐ │ 5. 自动部署测试│ (K8s Test Env) └──────┬────────┘ │ ┌──────▼────────┐ │ 6. 集成测试 │ (Postman/Newman) └──────┬────────┘ │ ┌──────▼────────┐ │ 7. 人工审批 │ (仅生产环境) └──────┬────────┘ │ ┌──────▼────────┐ │ 8. 自动部署生产│ (K8s Rolling Update) └────────────────┘实战GitHub Actions 配置.github/workflows/ci.ymlname: CI/CD Pipeline on: push: branches: [ main, develop ] pull_request: branches: [ main ] env: REGISTRY: registry.example.com IMAGE_NAME: order-service jobs: # 1. 代码扫描 sonar: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: SonarQube Scan uses: sonarsource/sonarcloud-github-actionv2 with: args: -Dsonar.projectKeyorder-service -Dsonar.organizationdicky -Dsonar.host.urlhttps://sonar.example.com -Dsonar.token${{ secrets.SONAR_TOKEN }} # 2. 构建 测试 build-test: runs-on: ubuntu-latest needs: sonar steps: - uses: actions/checkoutv3 - name: Set up JDK 17 uses: actions/setup-javav3 with: java-version: 17 distribution: temurin cache: maven - name: Build Test run: mvn clean verify -DskipTestsfalse # 3. 构建镜像 推送 build-push: runs-on: ubuntu-latest needs: build-test if: github.ref refs/heads/main steps: - uses: actions/checkoutv3 - name: Login to Registry uses: docker/login-actionv2 with: registry: ${{ env.REGISTRY }} username: ${{ secrets.REGISTRY_USER }} password: ${{ secrets.REGISTRY_PASSWORD }} - name: Build Push uses: docker/build-push-actionv4 with: push: true tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} # 4. 部署测试环境 deploy-test: runs-on: ubuntu-latest needs: build-push if: github.ref refs/heads/main steps: - uses: actions/checkoutv3 - name: Deploy to K8s uses: steebchen/kubectlv2 with: config: ${{ secrets.KUBE_CONFIG }} command: set image deployment/order-service order-service${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} -n test # 5. 人工审批 部署生产 deploy-prod: runs-on: ubuntu-latest needs: deploy-test if: github.ref refs/heads/main environment: name: production url: https://order.example.com steps: - uses: actions/checkoutv3 - name: Deploy to Production uses: steebchen/kubectlv2 with: config: ${{ secrets.KUBE_CONFIG }} command: set image deployment/order-service order-service${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} -n prod最佳实践清单阶段最佳实践代码提交分支保护PR 必须经过 Code ReviewCI每次提交必须过单测代码扫描必须达标构建缓存依赖并行构建镜像多阶段测试单测覆盖 80%集成测试覆盖核心流程部署蓝绿/金丝雀发布先小流量验证回滚出问题一键回滚上一版本监控部署后自动检查服务健康状态K8s 滚动更新配置apiVersion: apps/v1 kind: Deployment metadata: name: order-service spec: strategy: rollingUpdate: maxSurge: 25% # 先启 25% 新 Pod maxUnavailable: 25% # 最多关 25% 旧 Pod template: metadata: annotations: rollme: ${{ github.sha }} # 每次发布强制更新回滚方案自动回滚出问题时kubectl rollout undo deployment/order-service -n prod回滚到特定版本# 查看历史 kubectl rollout history deployment/order-service -n prod # 回滚到版本 2 kubectl rollout undo deployment/order-service --to-revision2 -n prod安全建议Secrets 不要写在代码里用 GitHub Secrets 或 K8s Secret镜像扫描用 Trivy 扫漏洞权限最小化CI/CD 账号只给必要权限签名镜像签名防止篡改最终效果指标优化前优化后发布周期半天10 分钟发布频率每月1次每天 N 次发布错误率20% 1%回滚时间1 小时1 分钟说到 CI/CD我家那只叫 Docker 的哈士奇最近吃饭也流水线化了闻一闻 → 咬一口 → 咽下去 → 下一块整个流程丝滑顺畅跟我们的流水线有的一拼 我是迪哥这 10 篇系列文章就到这里感谢大家一路陪伴往期推荐10 篇完《亿级流量系统性能优化实战》《JVM 调优让系统性能提升3倍》《从单体到微服务架构拆分实战》《Redis 高可用架构实战》《分布式链路追踪实战》《Kubernetes 生产环境部署与弹性伸缩》《MySQL 分库分表实战》《消息队列 Kafka/RocketMQ 选型与高可用》《Go 语言高并发服务性能调优实战》《Spring Cloud Alibaba 微服务全家桶》《系统容量规划与压测实战》《线上故障排查与应急响应》《云原生可观测性体系建设》《DevOps CI/CD 流水线最佳实践》