你以为搞个流水线每天跑,团队就在使用CI/CD实践了?
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
DevOps在路上
扫码关注公众号
扫码阅读
手机扫码阅读
流水线设计实践摘要
在DevOps实践中,团队对流水线的理解常常偏差,要么建立过多流水线,要么只用一个流水线处理所有情况。流水线设计应基于业务场景,并考虑到开源工具搭建的流水线需要更精细的安排,比如商业平台通常已经集成了设计理念。
流水线设计原则
- 确定变量:识别哪些变量在构建或部署时需要改变,如构建参数、代码地址等,避免硬编码。
- 规范命名:标准化流水线变量和命名,方便团队理解和快速复制流水线。
- 一次构建,多次部署:避免重复打包,支持多套环境配置和构建版本标签。
- 步骤标准化/原子化:标准化如Docker构建、Helm部署等步骤,根据业务需要组装流水线。
- 快速失败:将不稳定或耗时短的步骤放在流水线前面,提高反馈速度。
设计流水线的步骤
设计流水线时,应逐步实施,从单一步骤到完整流程,确保与业务需求和团队节奏匹配。应对价值流进行建模,自动化构建、部署、测试和发布过程。
流水线的分层
根据产品形态、团队构成和分支策略的不同,流水线设计应基于实际业务场景,这是衡量工程实践成熟度的关键。
DevOps流水线设计的最佳实践
- 提交构建流水线:适用于个人开发阶段,提供快速质量反馈。
- 集成验收流水线:团队级别流水线,适用于团队共享的环境。
- 部署测试流水线:由测试工程师针对提测版本使用的自动化流水线。
- 多组件集成流水线:当产品由多个组件组成时,用于集成打包。
- 单功能流水线:适用于与代码变更无关的场景,如漏洞扫描、自动化测试等。
- 全功能(持续交付)流水线:包含需求、代码构建、测试和部署环境的自动化流水线,适用于快速发布服务。
流水线运转全景图
在日常开发中,研发工程师每天至少提交一次代码,因此流水线每天多次启动。并非所有提交都会经历完整的流程,流水线会根据各个阶段的门禁验证确保最终交付的软件质量。
DevOps在路上
DevOps在路上
扫码关注公众号
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
DevOps在路上的其他文章
什么是软件研发的工程化?研发团队真的理解吗?
在实际和团队接触的过程中,我发现很多人不理解什么是“软件工程化”,包括在一些头条评论区看到“大言不惭的说sh
DevOps落地实践点滴和踩坑记录-(2) -聊聊平台建设
很久没有写文章记录了,上一篇文章像流水账一样,把所见所闻一个个记录下来。这次专门聊聊DevOps平台的建设吧
基于Drone+Gogs流水线-全面认识轻量级云原生CI引擎Drone
1. 介绍Drone by Harness™ 是一个基于Docker容器技术的可扩展的持续集成引擎,用于自动
Jenkins集成GitLab的正确姿势,实现Git代码提交触发CI/CD
❝jenkins和gitlab是目前DevOps工具链中最常见的,抛开gitlab-ci不谈,gitlab代码
Hey, man, you break the build!Jenkins邮件你收到了吗?
❝上一篇文章,我们提到了持续集成失败要立即修复。“反馈”是DevOps三要素之一的,那么流水线失败的通知邮件就算是其中一种反馈动作。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线