CI（consistent integrate）持续集成：开发人员频繁将代码提交到共享仓库（如 Git），每次提交后自动触发构建（编译、打包）和自动化测试（单元测试、集成测试），快速发现代码集成问题。
CD（consistent delivery）持续交付和部署：
CI/CD 是一套 “自动化软件交付流程” 的统称，核心目标是缩短开发周期、减少人工干预、提高交付质量。
CI/CD 核心：根据事先设置好的条件规则，当触发这些条件后，自动执行某些任务
为什么需要自动化发布：将项目发布到多个服务器上时，需要经常性的变更配置文件等，人工发布则会产生很多的失误，阻塞需求进度。而自动化发布，可以免去人工编译、部署时可能发生的人为失误。
Jenkins 是一款开源的自动化服务器工具，核心定位是实现持续集成（CI）和持续部署（CD）流程的自动化，被广泛用于软件开发生命周期中 “构建 - 测试 - 部署” 环节的自动化管理。它的灵活性和可扩展性使其成为行业主流的 CI/CD 工具，尤其适合需要高频迭代、多环境协作的团队。
传统开发中，代码提交后需要手动编译、运行测试、打包部署，效率低且易出错。Jenkins 可以通过配置 “流水线（Pipeline）”，实现从 “代码提交” 到 “生产环境部署” 的全流程自动化：
支持几乎所有主流开发语言（Java、Python、Go 等）、构建工具（Maven、npm、Gradle）、版本控制工具（Git、SVN）、测试工具（Jmeter、Pytest、Selenium）和部署目标（服务器、K8s、云平台），兼容性极强。
所有流程步骤（构建日志、测试结果、部署状态）均可视化展示，便于开发者和测试人员快速定位问题（如 “哪次提交导致测试失败”“部署到哪个环境出了错”）。
核心架构
Jenkins Master：核心服务器，负责管理任务（Job）、调度流程、展示结果，是用户操作的入口（通过 Web 界面）。
Jenkins Agent（节点）：执行实际任务的 “工作节点”（可是物理机、虚拟机或容器），Master 会将任务分配给 Agent 执行（避免 Master 负载过高）。
例如：可以配置 “测试节点” 专门运行 JMeter 压力测试，“部署节点” 专门执行生产环境部署，实现任务隔离。
插件生态（核心优势）
Jenkins 本身是轻量框架，功能主要通过插件扩展，目前官方插件市场有 1000+ 插件，覆盖几乎所有开发场景：
流水线（Pipeline）：定义自动化流程的 “代码”
流水线是 Jenkins 最核心的功能，通过代码（Groovy 语法） 定义自动化流程（即 “Pipeline as Code”），流程步骤（如拉代码、编译、测试、部署）可被版本化管理（和代码一起存在 Git 仓库），支持复杂逻辑（分支判断、循环、并行执行）。
示例（简化的测试部署流水线）：
pipeline {
agent any // 任意节点执行
stages {
stage('拉取代码') { // 阶段1：拉取Git代码
steps {
git url: 'https://gitlab.com/xxx/project.git', branch: 'main'
}
}
stage('运行自动化测试') { // 阶段2：执行Pytest用例
steps {
sh 'pip install -r requirements.txt' // 安装依赖
sh 'pytest test/ --html=report.html' // 生成测试报告
}
}
stage('部署到测试环境') { // 阶段3：测试通过后部署
when { success() } // 仅当前面阶段成功时执行
steps {
sh 'docker build -t myapp:latest .' // 打包镜像
sh 'docker run -d -p 8080:8080 myapp:latest' // 启动容器
}
}
}
post { // 流程结束后操作
failure { // 失败时发通知
dingtalkSend message: '测试失败，请查看Jenkins日志'
}
}
}
开发阶段：提交代码即触发测试
配置 “Git 提交触发”：开发者 push 代码后，Jenkins 自动拉取最新代码，运行单元测试、静态代码检查（如 SonarQube），若失败则立即通知开发者（如邮件 / 钉钉），避免问题流入后续环节。
测试阶段：自动化测试与压力测试集成
部署阶段：多环境自动化部署
区分 “测试环境”“预生产环境”“生产环境” 流水线：
传统开发流程（如 “瀑布式”）存在以下痛点，CI/CD 通过自动化流程解决这些问题：
Jenkins 是一个开源的自动化服务器，通过插件生态支持几乎所有主流开发工具和流程，是实现 CI/CD 的核心工具。
在 CI/CD 中的角色：
Jenkins Pipeline 是用代码定义 CI/CD 流程的工具，通过Jenkinsfile（存放于项目代码仓库）描述从构建到部署的全流程，支持两种语法：
pipeline { ... }包裹）；推荐使用 Pipeline 的原因（相比传统自由风格 Job）：
Jenkinsfile与项目代码一同存入 Git，可追踪流程变更（如谁修改了部署步骤），便于回溯。以 “Spring Boot 项目” 为例，流程为：拉取代码→编译打包→单元测试→构建 Docker 镜像→推送到镜像仓库→部署到测试环境。对应的Jenkinsfile（声明式）如下：
pipeline {
agent any // 可指定在特定Agent执行（如label 'java-agent'）
environment { // 环境变量
GIT_REPO = 'https://github.com/xxx/springboot-demo.git'
IMAGE_NAME = 'demo-app:${BUILD_NUMBER}' // BUILD_NUMBER是Jenkins内置变量（构建序号）
REGISTRY = 'harbor.xxx.com' // 镜像仓库地址
}
stages { // 流程阶段
stage('拉取代码') {
steps {
git url: "${GIT_REPO}", branch: 'dev' // 拉取dev分支代码
}
}
stage('编译打包') {
steps {
sh 'mvn clean package -DskipTests' // Maven编译打包（跳过测试，测试单独阶段执行）
}
}
stage('单元测试') {
steps {
sh 'mvn test' // 执行单元测试
}
post { // 测试后动作
always { // 无论成功失败都执行
junit 'target/surefire-reports/*.xml' // 生成测试报告
}
}
}
stage('构建Docker镜像') {
steps {
sh """
docker build -t ${IMAGE_NAME} . // 基于项目根目录的Dockerfile构建镜像
docker tag ${IMAGE_NAME} ${REGISTRY}/${IMAGE_NAME} // 打镜像仓库标签
"""
}
}
stage('推送镜像到仓库') {
steps {
withCredentials([usernamePassword(credentialsId: 'harbor-cred', usernameVariable: 'USER', passwordVariable: 'PWD')]) {
// 使用凭证登录镜像仓库（harbor-cred是在Jenkins中配置的凭证ID）
sh "docker login -u ${USER} -p ${PWD} ${REGISTRY}"
sh "docker push ${REGISTRY}/${IMAGE_NAME}"
}
}
}
stage('部署到测试环境') {
steps {
sshagent(credentials: ['test-server-ssh']) { // 使用SSH凭证连接测试服务器
sh """
ssh root@test.xxx.com '
docker pull ${REGISTRY}/${IMAGE_NAME} &&
docker stop demo-app || true &&
docker rm demo-app || true &&
docker run -d --name demo-app -p 8080:8080 ${REGISTRY}/${IMAGE_NAME}
'
"""
}
}
}
}
post { // 整个Pipeline结束后动作
success {
emailext to: 'dev@xxx.com', subject: '构建成功', body: 'CI/CD流程已完成，测试环境已更新'
}
failure {
emailext to: 'dev@xxx.com', subject: '构建失败', body: '请查看Jenkins日志排查问题'
}
}
}
Jenkins 的节点分为 Master 和 Agent，两者分工不同：
Master（主节点）：
负责核心管理工作：接收任务请求、解析 Pipeline、调度任务到 Agent、展示构建结果、管理插件和凭证等。
不建议直接执行构建任务（避免因资源消耗影响自身稳定性）。
Agent（从节点）：
负责实际执行构建 / 部署任务（如编译代码、跑测试、打包镜像），由 Master 分配任务。可在不同机器上部署（如 Windows、Linux、Docker 容器），支持按标签（Label）分类（如java-agent、nodejs-agent），便于任务按需分配。
需要 Agent 的原因：
Jenkins 涉及代码、凭证、服务器权限等敏感信息，需从多维度保障安全：
凭证管理：
withCredentials引用，避免硬编码。权限控制：
节点安全：
代码安全：
插件与版本安全：
构建失败是 CI/CD 中的常见场景，排查步骤通常为：
查看构建日志：
进入 Jenkins 对应构建的 “控制台输出”，定位失败阶段（如编译失败、测试失败、部署超时），重点关注错误信息（如mvn compile报错 “依赖缺失”、docker run报错 “端口被占用”）。
检查环境一致性：
mvn package），确认是否因本地与 Agent 环境差异导致（如依赖版本、JDK 版本不同）。验证依赖与配置：
调试 Pipeline：
sh 'pwd'、sh 'ls'等命令打印信息，或使用input步骤暂停流程，手动检查中间状态。查看系统资源：
若构建超时或无响应，检查 Agent 节点的 CPU、内存、磁盘空间（如磁盘满导致无法写入文件，内存不足导致 JVM 崩溃）。
