一、传统软件开发现状（DevOps 诞生背景）
传统模式：开发团队、测试团队、运维团队相互独立，部门墙明显。
- 开发 Dev：负责写代码，追求快速迭代、上线新功能；本地跑通就交付，不关心线上环境。
- 测试 QA：功能、回归测试，找 bug。
- 运维 Ops：负责部署、服务器、监控、保障线上稳定，害怕变更，抗拒频繁发布。
痛点：
- 开发环境、测试环境、生产环境不一致，“在我电脑上能跑”；
- 交付周期长，版本发布人工操作多，容易出错；
- 部门沟通成本高，故障互相甩锅；
- 手动部署、回滚，重复劳动，效率低；
- 业务需求迭代快，传统流程跟不上业务速度。
DevOps 就是打通开发‑测试‑运维的一套理念、文化、流程与工具链，消除部门壁垒，缩短软件交付周期，保障交付质量。
二、DevOps 概念
- DevOps 不是某一款软件，是一套方法论（文化 + 流程 + 工具）
- Dev（Development）开发；Ops（Operations）运维；
- 核心：开发和运维紧密协作，打通从代码提交到线上发布的完整链路。
- 核心目标
- 持续快速交付高质量软件；缩短从 idea 想法到线上可用的时间；
- 自动化重复工作：编译、构建、测试、部署、回滚；
- 快速反馈：测试反馈、线上监控反馈给到开发；
- 故障共同承担，共同改进，而不是互相甩锅。
DevOps 三大支柱
- 文化 Culture：打破部门墙，开发运维协作，责任共担；
- 流程 Process：标准化软件交付流程；
- 工具 Toolchain：工具链落地自动化流程。
三、DevOps 持续交付环（无限循环，八大环节）
闭环循环，不断迭代优化
- Plan 规划：需求分析、产品规划、排期、确定功能；
- Code 编码：开发编写业务代码；使用 Git 版本控制管理源代码；
- Build 构建：编译代码，打包制品（jar/war、docker 镜像）；
- Test 测试：单元测试、集成测试、功能测试、自动化测试；
- Release 发布准备：版本确认、制品归档；
- Deploy 部署：将版本部署到测试、预发布、生产环境；
- Operate 运维运营：线上运行、监控、日志、告警、容量管理；
- Monitor 监控反馈：采集线上指标、故障反馈，反馈给 Plan 规划阶段，进入下一轮迭代。
关键理念：反馈闭环，线上问题反馈给开发，驱动产品和代码优化。
四、CI / CD 核心概念（DevOps 最核心实践）
CI 持续集成 Continuous Integration
- 频繁把多人的代码合并到主干仓库，自动化构建 + 自动化测试。
- 开发人员频繁提交代码到 Git 仓库；触发自动化构建、单元测试、代码检查。
- 目的：尽早发现编译错误、单元测试失败、代码缺陷，尽早暴露问题。
CI 重点：代码提交后自动做【构建 + 测试】。
CD 有两层含义
- 持续交付 Continuous DeliveryCI 完成之后，制品随时处于可部署状态；可以一键部署到任意环境（测试、预发）；生产环境部署需要人工确认触发，不会自动上生产。
- 持续部署 Continuous Deployment在持续交付基础上，全部自动化，无需人工干预，自动部署到生产环境。风险高，一般仅用于内部非核心业务。
通俗区分
- CI：代码提交自动构建、自动测；
- 持续交付：可一键部署，生产要人工点按钮；
- 持续部署：测试通过自动直接上生产。
五、DevOps 工具链（各环节对应工具）
表格
| 环节 | 常用工具 |
|---|---|
| 代码版本管理 | Git、GitLab、Gitee、Github |
| CI 流水线执行引擎 | Jenkins（老牌）、GitLab‑CI、GitHub Actions、Argo‑CI |
| 制品仓库（保存构建产物） | Docker Harbor 镜像仓库、Nexus（jar/war/npm） |
| 配置管理 | Ansible、SaltStack |
| 容器编排 | Docker、Kubernetes |
| 监控告警 | Zabbix、Prometheus+Grafana、Alertmanager |
| 日志 | ELK(Elasticsearch Logstash Kibana)、Loki |
| 制品镜像 | Docker |
典型流水线完整流程示例：
开发git push代码 → GitLab接收代码 → Jenkins/GitLab‑CI触发流水线 → 拉取代码 → 代码检查 → 编译构建 → 单元测试 → 构建Docker镜像 → 推送到Harbor镜像仓库 → 部署到K8s测试环境 → 自动化集成测试 → 人工确认 → 部署预发布/生产K8s集群
六、制品 Artifact（构建产物）
- 制品：代码经过编译打包输出的产物，不包含源代码。 Java：jar、war；Go：二进制程序；容器场景：Docker 镜像。
CI 不要每次重新从源码构建，制品一次构建，多环境复用。测试、预发、生产使用同一个制品，避免 “环境不一样导致 bug”。
七、Git 版本控制基础
- Git：分布式版本控制系统；每一个本地仓库拥有完整版本历史。
- 核心概念：工作区、暂存区 (stage/index)、本地仓库、远程仓库 origin。
- 基础命令
git clone 地址 #克隆仓库 git add . #工作区提交到暂存区 git commit -m "备注" #暂存提交本地仓库 git push origin main #推送到远程main分支 git pull #拉取远程更新合并本地 git branch #查看分支 git checkout / switch #切换分支- 分支策略
main/master：保护分支，代表线上稳定版本，不允许直接 push；- 开发从 main 拉取 feature 功能分支开发；开发完成提 Merge Request (MR)/Pull Request (PR) 合并回 main；
- 生产出 bug，从 main 拉 fixbug 热修复分支，修复后合并回 main。
GitLab：自建 Git 代码仓库平台，自带 CI 流水线、MR、项目管理。
八、Jenkins 简介（经典 CI 工具）
- Jenkins 基于 Java 开发，开源 CI 服务器；可以实现自动化流水线。
- 组成
- Master 主节点：web 界面，管理任务、调度；
- Agent 代理节点：执行构建任务，分布式构建，减轻 master 压力。
- 触发方式：代码提交 webhook 钩子触发、定时触发、手动点击构建。
- 两种流水线写法
- 自由风格项目：图形页面配置，适合简单任务，难以版本化；
- Pipeline 流水线（Jenkinsfile）：代码式流水线，Groovy 语法，可以存放在 Git 仓库，Pipeline as Code 流水线即代码，生产推荐。
Jenkinsfile 典型阶段
pipeline { agent any stages { stage('拉取代码') { steps { ... } } stage('编译构建') { steps { ... } } stage('单元测试') { steps { ... } } stage('构建镜像') { steps { ... } } stage('推送镜像仓库') { steps { ... } } stage('部署测试环境') { steps { ... } } } }九、流水线环境区分
- dev 开发环境：开发自测；
- test 测试环境：QA 测试；
- staging 预发布环境：和生产配置 1:1，做上线前验证；
- prod 生产环境：对外提供业务服务。
原则：同一个制品镜像，依次部署 dev‑test‑staging‑prod，禁止每个环境重新构建。
十、流水线核心最佳实践
- 制品一次构建，到处部署，不同环境只改配置，不改二进制 / 镜像；配置与代码分离（ConfigMap、环境变量）。
- 流水线各个阶段失败立即终止，失败及时告警通知。
- Pipeline as Code，Jenkinsfile 存入 Git，流水线本身版本管理。
- 环境隔离，测试环境不能访问生产数据库；权限管控。
- 流水线中做各类质量门禁：代码扫描、单元测试覆盖率不达标直接阻断流水线。
- 可回滚：保留历史版本，故障可以快速切回旧制品。
