你好，我是王潇俊。今天我和你分享的主题是：持续交付为什么要平台化设计？
专栏内容已经更新一大半了，我和你也基本上已经逐个聊透了持续交付最核心的五大部分内容，包括：配置管理、环境管理、构建集成、发布及监控、测试管理。理解了这五大部分基本内容，你也就已经基本掌握了持续交付的核心内容，以及整个闭环流程了。
我猜想你可能已经开始尝试在团队内部署一套持续交付体系了，在部署的过程中又碰到了一些问题：比如，是否要为不同的语言栈建立不同的构建和发布通道；又比如，我还滞留在手工准备环境的阶段，无法有效自动化，应该怎么办。
要解决这些问题，你就需要达到一个更高的高度了，即以平台化的思维来看待持续交付。
那么从今天开始，我们就一起来聊聊持续交付平台化的话题吧。
“平台化”这个词，你应该已经听到过很多次了吧。特别是互联网领域，我们都爱谈论平台化。那么，“平台化”到底是什么意思呢？
其实，早在20世纪70年代，欧洲的军工企业就开始利用平台化的思维设计产品了。当时的设计人员发现，如果分别研制装甲车、坦克和迫击炮的底盘，时间和金钱成本的消耗巨大。
因为这些武器的底盘型号不同，所以它们所需要的模具、零件也就不同，除了要分别设计、制造、测试、生产外，还要花费巨额成本建设不同的生产流水线，而且各底盘的保养和使用方式不同，需要进行不同的人员培训。可想而知，这样分别设计的成本是巨大的。
所以，这些军工企业们就决定要采用一个通用的底盘设计，然后在通用底盘上安装不同的炮管和武器，达到个性化的需求。
之后，这种平台化的设计和制造方法，在航空制造业和汽车制造业得到了广泛运用，获得了极大的成功，并一直被沿用至今。
而，互联网又再次给“平台化”插上了新的翅膀。互联网厂商平台化的玩法，往往是指自己搭台子，让其他人唱戏。也就是说，由互联网厂商自己提供一些基础保障能力，建立必要的标准，从而形成底层支撑平台；而由其他供应商或用户利用这个底层平台提供的服务，自己完成具体业务、功能流程设计，从而达到千人千面的个性化服务能力。
互联网厂商的这种做法，就使得企业的服务能力被放大到了极致。
持续交付要做到平台化的原因，主要可以归结为以下三方面。
随着软件技术的发展，任何企业最终都将面临多技术栈的现实。不同的技术栈，就意味着不同的标准、不同的工具、不同的方式，所以我们就必须要通过合理的持续交付平台，去解决不同技术栈的适配工作。
随着持续交付业务的发展，团队会越来越庞大，分工也会越来越明细。这就要求持续交付体系能够支持更大规模的并发处理操作，同时还要不断地提升效率。更重要的是，当持续交付成为企业研发的生命线时，它必须做到高可用，否则一旦停产，整个研发就停产了。
随着持续交付技术本身的发展，还会不断引入新的工具，或新的流程方法。如果我们的持续交付体系不能做到快速适应、局部改造、高可扩展的话，那它自身的发展与优化将会面临严峻的挑战。
以上三个方面的原因，决定了我们需要打造一套高可用、可扩展的持续交付平台。
在前面的几个系列中，我分享了很多与持续交付的选型、实践与做法相关的内容。那么，在持续交付平台化的系列中，我会和你一起去整合前面看似零散的内容。
为此，我总结了实现持续交付平台化的7个步骤，也可以说是7个方法论，通过对这7个步骤的思考，你将清楚，要构建一套持续交付平台：
具体需要做哪些工作；
资源有限时，如何取舍；
最重要的任务是什么；
外部对你的限制和帮助有哪些。
希望通过我的总结，结合之前的分享，你能把持续交付的各个阶段串联起来，形成自己的平台化思路。
第一步，确定模块及其范围
交付流水线的概念，我已经在专栏第一篇文章《持续交付到底有什么价值》中介绍过了。如果你记不太清楚了，可以再回顾一下这篇文章的内容。
持续交付平台的工作流程基本就是根据这个流水线确定的，即：由编码开始，经过集成编译，再部署到相应环境，进行测试，最后发布到生产环境的过程。
持续交付平台最终将完成这个端到端的过程，那么流水线的每一步都可以认为是一个模块。由此，整个平台的核心模块就是：代码管理、集成编译、环境管理、发布部署。
这四个模块是持续交付平台中最核心，最容易做到内聚和解耦的模块。每个核心模块的周围，又围绕着各种子模块，比如：
这样，如上图所示，根据交付流程划分完模块后，整个持续交付平台所要涵盖的大致范围也就确定了。
第二步，学会做减法
好的产品，都需要不断地做减法，持续交付平台也是如此。
我们已经在第一步罗列了需要完成的模块，但很显然，不可能一下子完成所有的这些模块设计和开发a。所以，持续交付平台设计的第二步，就如何抓住最核心的内容。
正如我在第一篇文章《持续交付到底有什么价值》中所说，并不是只有完整的端到端自动化才叫“持续交付”，代码管理，集成编译，环境管理、发布部署这四大核心模块，其实就是一个交付的闭环，只是交付的内容不同，但这些交付都是可测的、可评定的，所以并不是半成品。
因此，我们就可以考虑挑选最为重要或最为急迫的模块，优先加以实施。甚至，你可以优先实现这四个模块中的一个，先解决一部分问题。这样做减法的方式，我们称为横向缩小范围。
另外一种做减法的方式是减少纵向的深度。也就是优先支持单一的技术栈，或特定的、比较简单的场景，比如先搞定组织内的单体应用。
通过做减法先完成这个平台最核心模块的方式，可以控制平台的初建成本，而且效果也比较容易预期。比如，携程就是优先完成了发布部署模块，再逐步向持续交付的上游拓展。
而对于后续要做加法的事情，可以以后或者由其他团队慢慢补上，这才是平台的意义。
第三步，制定标准
研发任何系统，首先要记住一句话：“标准先行”。
我们谈到标准时，往往会涉及很多方面，比如：对外衔接的标准、对内沟通的标准；质量的标准，速度的标准等等。而对持续交付平台的设计来说，最重要的标准是定义各个模块交付产物的标准。
只有制定了标准，其他团队或者其他系统才能有据可依地逐步加载到这个平台之上。
不同的组织和企业，标准和规范的内容要求不一样。所以，我无法一一列举这些标准和规范，但是你一定要清楚，这是重中之重的一个步骤。
第四步，选择合适的驱动器
所谓驱动器，就是用来驱动整个持续交付流水线的引擎。
不同规模的团队，适合的驱动器不同：
第五步，抽象公共能力
既然我们要设计一个平台，自然就要把很多公共功能抽象到平台层处理。需要抽象的公共功能，主要包括：
账户与权限，包括单点登录，以及鉴权、授权体系等等；
用户行为日志，即任何行动都要能够被追溯；
消息通知，即提供统一的通知能力；
安全与故障处理，即系统级的防护能力和故障降级。
持续交付平台的设计，除了要抽象这些公共功能外，还需要考虑打通上下游系统的问题，比如需要从CMDB获取服务器信息，从应用中心获取应用信息等等。
第六步，考虑用户入口
完成了持续交付平台内部功能的设计后，就要考虑用户入口的问题了。
用户入口，是提供一个统一的站点、使用命令行格式、使用IDE插件，还是直接使用Jenkins系统作为与用户交互的界面，可以根据团队的资源、能力等实际情况进行选择。
通常情况下，我会比较建议为持续交付独立形成一个 Portal，这样不会受到其他系统的限制，你可以根据自己的设计更好地完成用户引导和使用体验的设想。
第七步，聚力而成
通过上面这六步，我们已经初步完成了持续交付平台的设计，之后就是如何实现的问题了。
其实，如何实现持续交付的平台化，主要看你的决心和实践。但一定要记住，如果你决定要实施一个持续交付的平台，那就一定要学会运用团队的力量。
比如，架构同学，一定能够在制定规范和架构方面给你建议和帮助；而运维同学，肯定在环境治理和部署方面比你更有经验。
所以，你要做的是搭好平台，利用团队优势共同建设持续交付体系。
以上的内容，就是搭建一套持续交付平台最关键的七个步骤了。这里，我们可以用一张图片，表示这个持续交付平台的大致架构。
因为技术和业务的复杂性不断增加，持续交付需要解决的问题也变得越来越复杂。所以，我们需要利用平台化的思想解决持续交付体系日益复杂的问题。
持续交付是一个需要所有研发团队共同参与的活动，持续交付平台的建设也同样需要借助各个团队、各个职能的力量。
如果你正在负责持续交付这件事情，你应该充分考虑如何搭台，让大家来唱戏这样件事情。
你所在的组织内，持续交付中的哪些内容需要其他团队协助呢？
感谢收听，欢迎你给我留言。
评论