3、软件开发流程基础：敏捷开发与DevOps、CI/CD流水线基础、软件版本管理与发布策略
3.1 从瀑布到敏捷：为什么我们不再“一步到位”
说实话，我刚入行那会儿，团队还在用瀑布模型。需求文档写三个月，开发干半年，测试再搞两个月。等产品上线，市场早就变了。我印象特别深，有个项目我们吭哧吭哧做了一年，上线第一天用户就说“这不是我们要的”。
后来我们转型敏捷开发。说白了，敏捷就是“小步快跑，持续交付”。它不追求一开始就把所有事情想清楚，而是通过短周期的迭代，快速拿到反馈，不断调整方向。
敏捷开发的核心原则，我总结下来就几条：
- 个体和互动 高于流程和工具。每天站会聊一聊，比看一堆邮件强。
- 可工作的软件 高于详尽的文档。代码跑起来，比写一百页设计文档更有说服力。
- 客户合作 高于合同谈判。让客户每个迭代都看到进展，而不是最后才验收。
- 响应变化 高于遵循计划。计划赶不上变化，拥抱变化才是常态。
你想想看，如果每个迭代只有两周，你还会把需求写成一本书吗？不会的。你会把精力放在最核心的功能上，快速实现，快速验证。
3.2 DevOps：打破开发与运维之间的那堵墙
敏捷开发解决了“开发快”的问题，但新的麻烦来了：开发交付得越来越快，运维却跟不上。开发说“我代码写好了，你赶紧上线”，运维说“你代码一堆坑，我怎么敢上？”
DevOps 就是来解决这个矛盾的。它不是什么新工具，而是一种文化。核心思想是：开发（Dev）和运维（Ops）不再是两个孤岛，而是一个团队。
我在项目中见过最典型的例子：开发用 Docker 打包应用，运维却还在手动部署。每次上线都要折腾到凌晨。后来我们引入 DevOps 实践，开发自己写部署脚本，运维参与代码审查。上线时间从 4 小时缩短到 15 分钟。
DevOps 的三大支柱：
- 文化：共享责任、互相理解。开发要懂运维的苦，运维要理解开发的急。
- 自动化：能自动的绝不手动。从代码提交到部署上线，全流程自动化。
- 度量：用数据说话。部署频率、故障恢复时间、变更失败率，这些指标要盯住。
3.3 CI/CD 流水线：让代码“自动跑”起来
CI/CD 是 DevOps 落地的核心实践。CI 是持续集成，CD 是持续交付/持续部署。我习惯把它们看作一条“流水线”：代码从提交到上线，每一步都是自动化的。
持续集成（CI）：开发者频繁地将代码合并到主干，每次合并都自动触发构建和测试。这样能尽早发现集成问题，而不是等到最后一天才“集成地狱”。
持续交付（CD）：在 CI 的基础上，自动将代码部署到类生产环境，确保软件随时可以发布到生产环境。说白了，就是“一键部署”的能力。
持续部署：更进一步，每次通过测试的代码都自动部署到生产环境。这个对自动化测试的要求极高，一般团队不建议直接上。
一个典型的 CI/CD 流水线长这样：
代码提交 → 代码检查（Lint） → 单元测试 → 构建镜像 →
集成测试 → 部署到测试环境 → 验收测试 → 部署到生产环境我常用的 CI/CD 工具组合：
| 环节 | 工具选择 | 说明 |
|---|---|---|
| 代码仓库 | GitLab / GitHub | 托管代码，触发流水线 |
| CI 引擎 | Jenkins / GitLab CI / GitHub Actions | 执行构建、测试任务 |
| 构建工具 | Maven / Gradle / npm | 编译、打包代码 |
| 容器化 | Docker | 将应用打包成镜像 |
| 配置管理 | Ansible / Terraform | 自动化环境配置 |
| 部署平台 | Kubernetes / 云原生服务 | 运行容器化应用 |
3.4 软件版本管理：给代码打上“身份证”
版本管理，说白了就是给软件的每个状态打一个标签。没有版本管理，你根本不知道线上跑的是哪个版本，出了问题也回退不了。
我推荐使用语义化版本控制（SemVer），格式是：主版本号.次版本号.修订号。
- 主版本号：做了不兼容的 API 修改。比如从 v1.0.0 到 v2.0.0，意味着用户需要改代码才能升级。
- 次版本号：新增了功能，但向下兼容。比如 v1.1.0，用户可以放心升级。
- 修订号：做了 bug 修复，功能不变。比如 v1.0.1，只管修，不改接口。
另外还有预发布版本，比如 1.0.0-alpha.1、1.0.0-beta.2。这些版本只用于测试，不能上生产。
我在项目中遇到过最头疼的事：版本号乱打。有人用日期当版本号，有人用 Git commit 的哈希值。结果线上出了问题，根本不知道哪个版本对应哪个代码。后来我强制要求：所有发布必须打 Tag，Tag 必须遵循 SemVer 规范。
3.5 发布策略：怎么“安全”地把代码推上线
版本号打好了，代码也测试通过了，接下来就是发布。发布策略决定了你的服务在更新过程中，用户会不会感知到“服务不可用”。
常见的发布策略有几种：
- 蓝绿部署：准备两套完全一样的环境（蓝环境和绿环境）。当前流量在蓝环境，新版本部署到绿环境。测试通过后，把流量切到绿环境。切换瞬间完成，用户无感知。缺点是资源成本翻倍。
- 滚动更新：逐步替换旧实例。比如有 10 个实例，先停 1 个，更新 1 个，再启动。等这个实例正常了，再更新下一个。优点是资源占用少，缺点是更新过程中新旧版本共存，需要兼容。
- 灰度发布（金丝雀发布）：先让一小部分用户使用新版本，观察没问题再全量发布。比如先放 1% 的流量到新版本，稳定后扩大到 10%，再到 50%，最后 100%。
我个人最推荐灰度发布。为什么呢？因为生产环境的问题，很多时候测试环境根本测不出来。比如某个用户的数据量特别大，或者某个浏览器的兼容性问题。灰度发布可以让你在影响范围最小的情况下，发现这些问题。
总结一下发布策略的选择：
| 策略 | 适用场景 | 风险等级 |
|---|---|---|
| 蓝绿部署 | 对停机时间零容忍，资源充足 | 低 |
| 滚动更新 | 资源有限，服务无状态 | 中 |
| 灰度发布 | 高风险变更，需要验证 | 低（但流程复杂） |
嗯，到这里，软件开发流程的基础就讲完了。从敏捷开发到 DevOps，从 CI/CD 到版本管理和发布策略，每一步都是为了让软件交付更快、更稳、更安全。下一章我们会深入聊聊硬件开发流程，看看硬件和软件在协同交付中会遇到哪些坑。