大讲堂
别再把CI/CD当DevOps的万能补丁
很多人对CI/CD的认知从一开始就错了。 他们觉得CI/CD就是一套自动跑脚本的工具——代码提交到仓库，自动拉代码、装依赖、跑测试、打镜像、推到服务器，整个流程没人管，就是完美的CI/CD。 错得离谱。 持续集成的核心从来不是自动跑脚本，而是打破团队之间的信息墙，让代码冲突在最早的阶段暴露。最早提出这个概念的工程师，当年是因为大家攒了一两个月的代码才往主干合一次，合的时候要花整整一周解决互相改了同一行代码的冲突，才想出“每个人每天至少把自己的代码合到主干一次，每次合入都自动跑全量验证”的方法。 而CD的两层边界，很多团队从来没搞清楚过：持续交付是把经过验证的可发布版本推到预发环境，最终的生产上线由人做决策；持续部署是把全链路打通，只要代码通过所有验证，就自动推到生产环境，中间没有人为卡点。
现在的CI/CD生态，已经卷成了什么样
如果你最近关注CI/CD领域的产品更新，会发现整个赛道的竞争早就过了“能不能搭流水线”的初级阶段。 开源阵营里，Jenkins从最早的可扩展插件集合，慢慢往云原生方向迭代；GitHub Actions靠着和代码仓库的深度绑定，把个人开发者的门槛压到了最低；ArgoCD靠着K8s生态的红利，几乎成了云原生部署环节的默认选项。商业阵营里，CloudBees、JFrog这些老牌玩家，早就把业务从流水线工具延伸到了制品库、安全扫描、合规审计的全链路；国内的云厂商也把CI/CD能力打包到自己的云服务套餐里，跟计算、存储资源捆绑售卖。 现在大家卷的点是什么？ 是能不能把之前要20分钟跑完的流水线，压缩到3分钟以内。 是能不能自动识别测试用例的优先级，把跟当前提交相关的测试先跑，无关的直接跳过，不浪费资源。 是能不能在流水线里嵌上代码漏洞扫描、镜像安全检查、云资源成本核算、数据合规校验的模块，让流水线从单纯的交付通道，变成全链路的管控节点。
被忽略的风险：流水线不是法外之地
我之前碰到过一个做电商的团队，为了图方便，把生产环境的数据库密码直接硬编码在Jenkins的全局配置里，结果一次配置文件泄露，整个生产库的用户数据直接被拖走，造成的损失够买十年的CI/CD商业授权。 还有去年闹得很大的GitHub Actions供应链攻击事件，攻击者往公开的开源Action组件里塞了恶意代码，只要用户的流水线里引用了这个组件，每次代码提交的时候，环境变量里存的云密钥、数据库密码就会被自动传到攻击者的服务器上。 流水线已经成为仅次于生产服务器的第二大攻击面。 但很少有团队意识到这个问题。大部分公司把CI/CD当成开发团队自己的事，安全团队根本不参与流水线的设计，甚至连流水线跑了哪些任务、引用了哪些第三方组件、存储了哪些敏感信息都不知道。更有甚者，为了让流水线跑的更快，把所有的安全扫描环节都关了，把镜像仓库的访问权限开成了公开，本来是为了减少人工操作、提升效率的工具，反而变成了整个系统里最脆弱的缺口。未来3年，CI/CD会往哪走
我跟几个在云厂商做DevOps产品的朋友聊过，大家的判断其实高度一致。 首先，AI会彻底重构CI/CD的使用门槛。现在很多人搭流水线要写几百行的yaml配置，要自己想清楚每个环节的依赖关系，未来AI会直接根据团队的代码栈、发布频率、合规要求，自动生成适配的流水线配置；还会自动分析每次提交的代码改动范围，智能判断需要跑哪些测试、哪些扫描，把之前动辄十几分钟的流水线压缩到1-2分钟；甚至AI可以自动评估改动的风险等级，判断这次发布要不要触发灰度、要不要回滚预案，把人从重复的决策里解放出来。 其次，整个赛道的商业模式会变。之前大家卖CI/CD工具，都是按账号数收年授权费，未来会慢慢转向按实际的交付价值收费——比如按流水线的执行次数、按发版的成功次数、按帮客户节省的运维人力成本收费，甚至直接给客户做全托管的流水线运营，客户不用招专职的DevOps工程师，厂商直接把整个交付链路的运维包下来。 最后，CI/CD的渗透边界会从互联网团队，延伸到更多传统行业。现在汽车行业的OTA升级、高端制造的工业软件交付、金融行业的核心系统迭代，其实都在慢慢引入CI/CD的流程。之前这些行业因为合规要求、系统稳定性要求高，不敢搞全链路的自动部署，但随着流程的成熟、安全能力的完善，未来3-5年，这些行业的CI/CD渗透率会从现在的不到10%，涨到30%以上。 说实话，我特别烦那种把CI/CD吹成“数字转型唯一答案”的培训课。 真的。 你连自己的团队每天要发几次版、每次发版要花多少时间、每次发版会出多少问题都没搞清楚，买再多工具都是白搭。 工具从来都不是目的。 能让团队少加班，能让用户少碰到线上bug，才是。作者|大讲堂
排版|大讲堂
审核|满满