23 | 持续交付平台：现代流水线必备的十大特征（上）

石雪峰



该思维导图由 AI 生成，仅供参考

你好，我是石雪峰。
作为 DevOps 工程实践的集大成者和软件交付的“理想国”，持续交付对企业的 DevOps 落地起到了举足轻重的作用。我接触过的企业全都在建设自己的流水线平台，由此可见，流水线是持续交付中最核心的实践，也是持续交付实践最直接的体现。
那么，如何建设一个现代流水线平台呢？这个平台，应该具备哪些特性呢？
根据我自己在企业内部建设落地流水线平台的经验，以及业界各家公司的平台设计理念，我提取、总结了现代流水线设计的十大特性。
在接下来的两讲中，我会结合平台设计，给你逐一拆解这些特性背后的理念，以及如何把这些理念落地在平台设计中。我把这十个特性汇总在了下面的这张图片里。今天，我先给你介绍下前五个特性。
特性一：打造平台而非能力中心与其他 DevOps 平台相比，流水线平台有一个非常典型的特征，那就是，它是唯一一个贯穿软件交付端到端完整流程的平台。正因为这样，流水线平台承载了整个软件交付过程方方面面的能力，比如，持续集成能力、自动化测试能力、部署发布能力，甚至是人工审批的能力等。
那么，我们把软件交付过程中所需要的能力都直接做到流水线平台上，是不是就可以了呢？
这个想法是好的，但是在企业中，这并不具备可操作性。因为软件交付的每一个环节都是一项非常专业的工作，比如，仅仅是自动化测试能力这一项做好，就需要一个具备专业技能的团队的长期投入。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

现代软件开发中，持续交付平台扮演着至关重要的角色。本文介绍了现代流水线平台的五大特征。首先，流水线平台应定位为持续交付的任务调度者和执行者，而非能力中心。其次，平台需要具备可编排和可视化的能力，以满足多样化开发模式的需求。另外，文章还提到了流水线即代码的概念，即通过代码化的方式描述流水线，以便追溯每次流水线的变更记录。此外，流水线需要支持参数化执行、实例化和有限支持原则。这些特性的实现将有助于提升软件交付的效率和灵活性。文章还提出了思考题，鼓励读者分享自己的思考和答案，以促进共同学习进步。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《DevOps 实战笔记》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(13)

最新
精选

陈斯佳
真想去哪个大公司看看他们的Jenkins是怎么用的…
作者回复: 哈哈，欢迎来我们公司参观呀😄
2019-12-13

5
iiiqueena
atlassian的Bamboo也做得挺好的
作者回复: 呵呵，我们内部的平台也是叫做Bamboo，原来不是特别理解，后来才想明白，原来是指代竹子一节节的好像流水线一样哈。其实，我这里讲的很多内容都融入了我们自己的产品设计中，部分参考代码也是我们真实项目中的哈。
2019-12-10

4
小谢同学
想问老师如果对于外部市场需求的devops产品发生了同质化效应，无论核心功能还是价格，这怎么办？拼服务？
作者回复: 我理解同质化是必然的，你没发现每个工具都试图把自己打造成一个端到端的平台吗？但是，就我的观察和企业中的交流来看，往往这种大而全的平台反而不容易落地，相反那些能解决一个点的问题，或者能够串联已有能力平台的方案则更加受欢迎。我觉得回答这个问题要看站在哪个视角，大公司视角和初创公司视角肯定是不一样的。如果是我来选择，除了你提到的功能和价格，更加关注的是可扩展性和连通性方面哈！
2019-12-18

2
swordman
老师，是否有主流项目管理平台和jenins集成的实战分享？比如jira和jenkins。
作者回复: 你好，关于Jira和Jenkins 的集成实践，我会在27讲中给大家分享一个完整的案例哈，敬请期待
2019-12-11


t86
期待老师有结合实战的讲解
作者回复: 你好，27讲中会结合一个开源解决方案给大家串一下工具哈，敬请期待！
2019-12-10


阿硕
石老师，您好，请教下在jenkins的流水线中，多种不同工具的参数和变量传递有什么最佳实践方法吗？
作者回复: 你好，这么泛泛的说很难知道你的问题所在哈，你可以添加我的微信线下沟通，关于Jenkins的任何问题都可以随时找我哈，我的微信号码：cendrier，提前祝你新年快乐！
2019-12-10
2

快手阿修
看完这一章，我有两个关于流水线局部的细节设计，想跟石老师一起探讨一下。这也是我认为，团队目前在使用的流水线中，两个容易引发问题的点。在说具体的特性设计之前，先简单介绍下相关信息。目前我们使用的流水线，部署方式为shell 部署，包括停止服务、卸载老代码、安装新代码、启动服务4个操作步骤，分别由代码仓中4个shell 脚本控制步骤执行逻辑。(灰度切流相关操作与部署任务独立) 另外，每一条流水线会对应若干台部署机器，这些机器位于另外一个叫做CMDB 的微服务上管理，一条流水线对应CMDB 上一个组件，一个组件下管理着上面提到的若干台机器。一个组件可以对应若干条流水线。接着，来说一下上面提到的我认为两个影响使用的特性设计。 1、停止服务、卸载老代码2个步骤，使用上一次部署包中的脚本，之后的步骤使用这一次部署包中的脚本。 2、流水线构建时打的包的名字，必须与CMDB 上对应的组件名一致。上面的两个设计在日常工作中会带来两个问题(目前遇到的)。第1个问题，如果你改动到了部署脚本中的前2个步骤，那么需要连续部署两次才能看到你的最新修改。假设某一次的改动，不小心把上述2个步骤改错了导致任务失败(当然部署脚本改动的频
2021-10-18
2
1
leslie
流水线中嵌套流水线：DevOps其实只是大流水线中的一个小流水线。记得曾经在老师的课程中提及过DevOps是研发团队内部的ERP或进销存，只不过其关注的点不同而已。学到现在终于明白为何DevOps会被称为效率部门了，上次大会对DevOps定位有各种称呼了。谢谢老师的教诲，期待后续的分享。
2019-12-07

1
Sports
这五个原则真是高屋建瓴
2023-07-19归属地：江苏


Geek_a4cca6
关于有限支持原则这个点，我们其实也碰到了，但是如果不满足业务的所有需求，这玩意就是看来没有落地的，推动不起来，没产生效益；另外，我想请问下老师，对于一个规模不是很大的团队，例如5人做流水线这块的设计，请问用通过jenkins能做到这种流水线编排吗？
2021-11-18



收起评论