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