在云原生架构下做持续集成，最先要解决的是环境一致性问题。以前虚拟机时代用Jenkins打包，经常出现"本地能跑测试环境挂"的灵异事件。现在我们用容器化构建层，所有微服务的Dockerfile都统一放在代码库根目录。当Git提交触发webhook后，Jenkins会先拉取业务代码和Dockerfile，在容器内执行单元测试。这里有个关键细节：构建镜像不再用latest标签，而是采用"git commit id+时间戳"的命名规则，比如user-service镜像会生成user-service-3a8b9c-202312081530这样的标签。
镜像推送到Harbor仓库后，真正的云原生特性才开始显现。通过配置在K8s集群的ArgoCD会自动检测镜像仓库变化，但这里没有立即触发部署。我们设计了质量门禁机制：只有通过自动化API测试的镜像才会被同步到预发环境。这个环节我们栽过跟头------曾经有次数据库迁移脚本有问题，导致批量更新时锁表。现在会在Pipeline里加入数据库迁移校验步骤，使用Flyway工具在测试环境先执行schema检查。
生产环境发布更考验流水线设计水平。刚开始直接用的蓝绿部署，发现流量切换时总有零星事务异常。后来改成金丝雀发布，在入口网关配置5%的流量导向新版本，持续观察2个业务周期（我们按小时级业务周期来算）。监控体系在这里特别重要：不仅需要看Pod是否就绪，还要通过Prometheus采集业务指标（比如订单支付成功率），当错误率超过阈值就自动回滚。有次商品服务发版，就是靠这个机制在3分钟内发现了内存泄漏问题。
流水线安全是容易被忽视的环节。我们在镜像扫描阶段集成了Trivy工具，会阻断存在高危漏洞的镜像进入流水线下游。另外在K8s部署清单里严格限制了容器权限，所有微服务都不能以root身份运行。密钥管理方面用了SealedSecret，把数据库密码等敏感信息加密成K8s资源，只有目标命名空间的服务才能解密。
这套体系运行半年后，最直观的变化是发布频率从月发布提升到周发布。但更宝贵的是故障恢复能力：上周某个配置错误导致服务中断，我们通过ArgoCD的版本对比功能，10分钟就定位到是某个环境变量被误改，直接点击同步就完成回滚。这种效率在手动运维时代根本不敢想象。
当然坑也没少踩。最初把所有微服务的流水线都做成了统一模板，结果某个前端项目每次构建都要下载node_modules，拖慢整体流程。后来改成按技术栈分建流水线模板，Java项目用Maverse构建，前端项目用缓存优化。还有个教训是日志收集要及时配置，有次某个服务异常但容器已重启，差点丢失关键日志，后来补上了Fluent-bit日志采集。
现在看这条流水线，就像看着自己打磨的精密仪器。从代码提交到生产部署，每个环节都有反馈机制和安全防护。但云原生领域的工具迭代太快，最近在试验Tekton替代Jenkins，用GitOps模式把环境配置也纳入版本管理。或许明年再看这套流水线，又会是全新的模样。