【CI/CD】持续集成及 Jenkins

文章目录

传统与敏捷开发流程对比
CI/CD
- 持续集成（CI）
- 持续交付/部署（CD）
- [Jenkins Pipeline 语法](#Jenkins Pipeline 语法)
- [实施 CI/CD 的典型流程](#实施 CI/CD 的典型流程)
- 常见问题与解决方案~

传统与敏捷开发流程对比

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，灵活性高，适合复杂逻辑。

示例：

groovy 复制代码

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）

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

示例：

groovy 复制代码

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 的典型流程

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

常见问题与解决方案~

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

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

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

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

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

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

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

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

Q5：如何优化构建速度？

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