【CI/CD】持续集成及 Jenkins

传统与敏捷开发流程对比

1. 瀑布模型（Waterfall Model）

• 核心特点：线性顺序开发，严格分阶段（需求→设计→开发→测试→部署），各阶段需完全完成后进入下一阶段。
• 缺点：周期长（通常数月到数年），难以应对需求变更，测试滞后导致缺陷修复成本高。
• 适用场景：需求明确且稳定的项目（如航空航天软件）。

2. 敏捷开发（Agile）

• 核心特点：迭代开发（2-4周为一个Sprint），持续交付可工作的软件，强调客户反馈和团队协作。
• 优势：快速响应变化，早期交付降低风险，客户参与度高。
• 关键实践：Scrum/Kanban框架、每日站会、用户故事驱动。

---

CI/CD

通俗来说就是启动一个服务，能够监听代码变化，然后自动执行构建、测试、打包、发布等流程；CICD 是持续集成和持续交付/部署简称。
指在研发过程中自动执行一系列脚本来降低开发引入bug的概率，在新代码从开发到部署的过程中，尽量减少人工的介入。这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。

持续集成（CI）

指在开发人员频繁地提交新代码，都会自动执行构建、测试。根据测试结果，我们可以确定新代码能否合并到主分支。
假设现在有个应用的代码存储在仓库上，每天开发人员都会提交很多次新代码，针对每次提交，我们可以创建一系列脚本进行自动测试，降低往应用里引入错误的概率。
持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，如果构建或测试的失败，可以快速地反馈到相关负责人，以尽快解决达到一个更稳定的版本。

• 流程：开发提交代码 → 自动触发构建 → 编译 → 单元测试 → 生成报告 → 通知结果。
• 工具链示例：Git（代码库） + Jenkins（CI服务器） + Maven/Gradle（构建） + JUnit（测试） + SonarQube（代码质量）。
• 价值：减少集成冲突，快速发现缺陷，提升代码质量。

持续交付/部署（CD）

CD 持续交付：指将完成CI的最新代码部署到类生产环境进行功能验证，以确保新增的代码在生产环境中是可用的。
CD 持续部署：指在持续交付的基础上，通过自动化部署的手段将软件功能频繁的部署到生产环境中。

• 持续交付：确保代码随时可部署到生产环境，但发布需手动触发。
• 持续部署：全自动化发布，通过自动化测试后直接上线。
• 关键步骤：自动化测试（集成/E2E）→ 部署到预发布环境 → 冒烟测试 → 生产发布（滚动更新/蓝绿部署）。

Jenkins Pipeline 语法

1. 脚本式（Scripted）

• 特点：基于Groovy DSL，灵活性高，适合复杂逻辑。
• 示例：

  node('master') { // 指定运行节点
      stage('Checkout') {
          git url: 'https://github.com/project.git' // 拉取代码
      }
      stage('Build') {
          sh 'mvn clean package' // 执行构建命令
      }
      stage('Test') {
          junit '**/target/surefire-reports/*.xml' // 单元测试报告
      }
  }
  

• 变量作用域：def定义的变量在node{}块内有效，跨stage需在外部定义。

2. 声明式（Declarative）

• 特点：结构化语法，易读易维护，内置错误处理和阶段控制。
• 示例：

  pipeline {
      agent any // 在任何可用节点执行
      environment {
          VERSION = '1.0.0' // 全局环境变量
      }
      stages {
          stage('Build') {
              steps {
                  script {
                      if (env.BRANCH_NAME == 'main') {
                          sh 'mvn -B clean package' // 条件判断执行
                      }
                  }
              }
          }
          stage('Deploy') {
              when { expression { return params.DEPLOY_PROD } } // 条件执行
              steps {
                  sh "kubectl apply -f app-${VERSION}.yaml"
              }
          }
      }
      post {
          success {
              slackSend message: "构建成功: ${env.BUILD_URL}" // 构建后通知
          }
      }
  }
  

• 环境变量：通过environment{}定义，跨stage共享；withEnv可在step内临时设置。

实施 CI/CD 的典型流程

1. 代码提交：开发者推送代码至Git仓库（如GitLab）。
2. 触发构建：Webhook通知Jenkins启动Pipeline。
3. 代码检查：SonarQube扫描代码异味和漏洞。
4. 构建与测试：编译项目，运行单元/集成测试，生成制品（JAR/Docker镜像）。
5. 部署到测试环境：使用Ansible/K8s部署，运行自动化UI测试。
6. 人工审批（可选）：确认是否继续部署到生产环境。
7. 生产发布：金丝雀发布逐步切流，监控系统（Prometheus）观察运行状态。

---

常见问题与解决方案~

Q1：如何选择脚本式或声明式Pipeline？

• 声明式：推荐大多数场景，结构清晰，支持语法检查。
• 脚本式：需要复杂逻辑控制（如循环、异常处理）时使用。

Q2：CI中自动化测试失败如何处理？

• 立即停止Pipeline，通知开发者；测试报告集成到Jenkins界面便于追溯。

Q3：生产部署是否需要全自动？

• 视业务风险决定，金融系统可能需手动审批，互联网应用常全自动。

Q4：如何管理不同环境的配置？

• 使用配置管理工具（Ansible/Vault）或区分环境变量（如Spring Profiles）。

Q5：如何优化构建速度？

• 并行执行测试、缓存依赖（Nexus仓库）、分布式构建（Jenkins Agent）。