你以为搞个流水线每天跑,团队就在使用CI/CD实践了?
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
DevOps在路上
扫码关注公众号
扫码阅读
手机扫码阅读
流水线设计实践摘要
在DevOps实践中,团队对流水线的理解常常偏差,要么建立过多流水线,要么只用一个流水线处理所有情况。流水线设计应基于业务场景,并考虑到开源工具搭建的流水线需要更精细的安排,比如商业平台通常已经集成了设计理念。
流水线设计原则
- 确定变量:识别哪些变量在构建或部署时需要改变,如构建参数、代码地址等,避免硬编码。
- 规范命名:标准化流水线变量和命名,方便团队理解和快速复制流水线。
- 一次构建,多次部署:避免重复打包,支持多套环境配置和构建版本标签。
- 步骤标准化/原子化:标准化如Docker构建、Helm部署等步骤,根据业务需要组装流水线。
- 快速失败:将不稳定或耗时短的步骤放在流水线前面,提高反馈速度。
设计流水线的步骤
设计流水线时,应逐步实施,从单一步骤到完整流程,确保与业务需求和团队节奏匹配。应对价值流进行建模,自动化构建、部署、测试和发布过程。
流水线的分层
根据产品形态、团队构成和分支策略的不同,流水线设计应基于实际业务场景,这是衡量工程实践成熟度的关键。
DevOps流水线设计的最佳实践
- 提交构建流水线:适用于个人开发阶段,提供快速质量反馈。
- 集成验收流水线:团队级别流水线,适用于团队共享的环境。
- 部署测试流水线:由测试工程师针对提测版本使用的自动化流水线。
- 多组件集成流水线:当产品由多个组件组成时,用于集成打包。
- 单功能流水线:适用于与代码变更无关的场景,如漏洞扫描、自动化测试等。
- 全功能(持续交付)流水线:包含需求、代码构建、测试和部署环境的自动化流水线,适用于快速发布服务。
流水线运转全景图
在日常开发中,研发工程师每天至少提交一次代码,因此流水线每天多次启动。并非所有提交都会经历完整的流程,流水线会根据各个阶段的门禁验证确保最终交付的软件质量。
DevOps在路上
DevOps在路上
扫码关注公众号
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
DevOps在路上的其他文章
聊聊持续交付实践中的 “秩序感”
很久前,曾经问过大佬一个问题“企业文化不行,没有好的氛围,如何推动DevOps落地?
对象存储服务-Minio
「对象存储服务(Object Storage Service,OSS」)是一种海量、安全、低成本、高可靠的云
平台工程:降低认知负担,改善开发人员体验提升企业的数字生产力
为了逐步提升数字竞争力,中国的企业机构正在向组装式架构转型,推动了云原生平台、DevOps平台的采用。
解读平台工程,DevOps真的死了吗?不,它只是换了个马甲而已,弥补了DevOps空心理论,让DevOps继续发展壮大
平台工程这个概念越来越火爆,Gartner 的预测,到 2026 年,80% 的软件工程组织将拥有平台工程团队
从“没有CI/CD团队”进化到“使用CI/CD基础设施的团队,再到“使用AI基础设施的团队”
没有 CI/CD 的团队
项目创建
功能编写
代码提交
功
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线