云上持续交付与DevOps实践：从代码提交到生产部署的全流程自动化
上个月，一个做金融科技的朋友打电话给我，语气里全是疲惫：“我们每周发一次版，每次都是一场折腾。构建经常失败，测试跑不通，部署脚本每次都要手动改。CTO说我们要快，但每次上线都像在拆炸弹。”
我问他：“你们的流水线长什么样？”
他愣了一下：“什么流水线？”
这是太多团队的现状：代码有，服务器有，但从代码到服务器，中间缺了一条自动化的路。开发写代码，运维上线，中间是漫长的等待和焦虑。
今天聊聊云上持续交付与DevOps实践。不是那种“自动化一切”的口号，而是实打实的：怎么搭一条从代码提交到生产部署的自动化流水线，让发布从惊吓变成例行公事。
01 别把Jenkins当神供
很多人一聊CI/CD，第一反应就是“搭个Jenkins”。这没错，但问题在于：搭完以后，你还得养它。插件要升级，磁盘要扩容，构建任务多了要加节点，Jenkins本身成了一个新的运维负担。
在云时代，CI/CD已经变成了一种“水电煤”。每个云厂商都提供了托管服务，你不用自己养：
AWS：CodeCommit、CodeBuild、CodeDeploy、CodePipeline
Azure：Azure DevOps、GitHub Actions
Google：Cloud Build、Cloud Deploy
阿里云：云效、容器服务CI/CD
GitHub Actions现在已经有超过千万开发者在使用。它不是工具，是一个平台——你的流水线就住在代码旁边，代码在哪，流水线就在哪。
反常识观点：最好的CI/CD工具，是让你感觉不到它存在的那个。 如果你花在维护构建系统上的时间比写代码还多，那就本末倒置了。
02 一条正经的流水线长什么样
一条能上生产的流水线，至少要有这四个部分：
1. 代码仓库：GitHub、GitLab、CodeCommit。代码的唯一真实来源。每次提交都是流水线的起点。
2. 构建和测试：编译代码、跑单元测试、静态代码扫描、安全扫描。早发现早解决，测试挂了就停。
3. 制品库：把构建产物存起来，比如Docker镜像、jar包、安装包。每次构建都有唯一版本号，不可篡改。
4. 部署：把制品推到目标环境（开发→测试→预发→生产）。用滚动更新、蓝绿部署、金丝雀发布，别搞成停机替换。
这四样连起来，开发push代码，几分钟后就能跑到生产——不用人插手。
03 部署策略：怎么上线不翻车
很多团队在部署这件事上，还停留在“停掉老的，起新的”。这是最危险的玩法。
现代流水线用更安全的姿势：
滚动更新：一台一台换，旧的慢慢下线，新的慢慢上线。成本低，但新旧版本会共存一段时间。你的应用得扛得住版本混跑。
蓝绿部署：蓝环境是现网，绿环境是新版。全部准备好，切一下流量就过去了。回滚也是一键的事。缺点是切流时得准备两套资源。
金丝雀发布：先放1%的流量到新版，看几分钟没问题，再放10%、50%，直到全量。Netflix一天部署几千次，靠的就是这个。万一新版有问题，只砸到1%的用户。
反常识观点：工具不重要，策略才重要。 用蓝绿还是金丝雀，取决于你的业务容忍度。但无论如何，别用“停服替换”。
04 安全左移：别等上线才发现问题
“安全左移”听着玄乎，其实就是：把安全检查和测试往左推，推到开发阶段去。
单元测试：每次push都跑，覆盖率不够直接失败
静态代码扫描：用SonarQube、Snyk，找出SQL注入、硬编码密钥
容器镜像扫描：用Trivy、Grype，扫出已知漏洞再推镜像库
基础设施检查：用checkov、tfsec，验证Terraform代码别犯低级错误
一个客户曾经在代码里硬编码了云密钥，放了六个月没被发现，直到安全审计。后来我们在CI里加了一步gitleaks扫描，第二次有人硬编码密钥，几个小时内就被拦截了。
安全左移不是为了完美，是为了让错误在伤害最小的时候被发现。
05 一个真实案例：从手动部署到每天多次上线
去年帮一个媒体创业公司改造。他们的流程是这样的：
开发写完代码，手动打tag
找个开发服务器手动编译
用SFTP把文件传到测试服务器
手工执行SQL脚本
上线那天所有人守在电脑前，祈祷别出问题
我们分了三步走。
第一步：构建自动化。代码迁到GitHub，用GitHub Actions跑测试、打镜像，推ECR。构建部分先跑通。
第二步：部署自动化。用CodeDeploy把镜像自动部署到测试环境，测试通过后加一个人工确认，再推生产。
第三步：安全发布。生产切到蓝绿部署，上线后自动跑冒烟测试，失败自动回滚。
三个月后，他们从每周一次提心吊胆的发布，变成每天多次发布，没人再为上线加班。部署相关故障下降了90%。
CTO说：“以前觉得CI/CD就是工具，现在才知道，它是让发布变得无聊的机制。”
06 流水线也要当代码管
流水线本身也是代码。别在控制台上点来点去。
把流水线配置写进代码仓库（比如GitHub Actions的YAML、CodePipeline的CloudFormation），和你的应用代码放在一起。这样：
流水线变更要经过review
坏了可以回滚
新人来了看代码就知道怎么跑
把流水线当代码，你才真正拥有了可重复、可审计的交付过程。
07 从哪开始
别一上来就想建个Netflix级的流水线。先做最小闭环：
一个仓库
一个测试（单元测试）
一个环境（测试环境）
跑通这个闭环，再加集成测试、加安全扫描、加生产部署、加金丝雀、加自动回滚。
目标不是完美，是可靠。一条简单但靠谱的流水线，比一条复杂但没人信的流水线强一万倍。
写在最后
那个做金融科技的朋友，后来我们帮他搭了第一条流水线。从代码提交到测试环境自动部署，花了两周。又过了一个月，生产环境也用蓝绿部署跑起来了。
他发消息给我：“五年了，第一次上线没害怕。”
持续交付不是一锤子买卖，是你团队长出来的肌肉。每提交一次代码，每跑一遍测试，每部署一回，这块肌肉就结实一分。等哪天凌晨要发紧急补丁的时候，你会庆幸——这条流水线，早就给你铺好了路。
你团队现在的发布，还让人害怕吗？
