图 4. DevOps 流水线交付平台整体架构图
显然，在 DevOps 流水线工具平台实施的四层架构中，其核心是流水线工具平台层的搭建，对上，该工具平台需要通过流水线引擎与现有的流程管理系统对接，对下，则需要兼容现有的各种程序语言、开发发布模式、构建方式，以及存量硬件和云平台的基础设施。在本系列文章的后续各篇中，我们将重点围绕流水线工具平台的搭建进行阐述。
实施思路讨论
流水线交付平台各层实施顺序
对于第四节所述工具平台的实施，不同的企业具体的实际情况可能会略有差别，因此，不可能对所有的企业都采用同样的思路进行实施;同时，对于大型企业来说，由于产品形态的多样化，开发语言的广泛性，各开发团队情况的差异性，该工具平台的完整实施也是不可能一蹴而就的。在具体实施时，需要根据具体情况选择制定相应的策略进行实施。总结而言，有两个维度的问题需要考虑，一个是这四层的实施顺序，另一个则是对于流水线工具平台层中，各个具体工具的实施思路。
从上到下的四层中，根据逻辑上的耦合性，我们将其分成了三组，流程管控层自成一组，称为第一组，流水线执行引擎及流水线工具平台层作为一组，称为第二组，基础架构自成一组，称为第三组。
对于目前大多数的金融企业来说，现在基本都已经存在相应的开发测试发布管控流程，不同的只是成熟度不同而已。因此，流水线管控这一层更多的应该是考虑如何对已有流程进行优化。开发测试发布流程中各个阶段的划分和衔接肯定会影响到流水线执行引擎的实施，因此，这一层的实施可与第二组同时进行，或者在第二组实施之前，但不能在第二组之后。
基础架构层中如果存在云平台，则对流水线工具平台层的影响是流水线工具平台需要扩展到对云平台的兼容，因此，第三组与第二组之间既可同时实施，也可先后实施，只不过，如果是第二组先实施之后再实施第三组的云平台，则第三组实施后，需要对第二组进行扩展。
第二组的两层中，流水线引擎是基于流水线工具平台进行的，因此，流水线执行引擎一定得在流水线工具平台之后实施。因此，完整的实施顺序如图 5 所示。
图 5. DevOps 流水线各层实施顺序
流水线工具平台层实施思路
在流水线工具平台层中，对于开发测试发布过程的不同阶段，相应的存在配置管理、代码构建、静态分析、自动化测试、构建包管理、自动化部署、监控等众多工具，其实施过程相对较长，也比较复杂。在具体实施时，存在两种可能的思路，一种为逐点突破，然后再全部连接成一个完整的工具平台。这种思路下，会对企业整体的交付流水线进行分析，找出其中最大的痛点(如配置管理、构建管理或者自动化部署等)，然后重点实施，并推广至全公司，接着再继续实施下一个痛点，通过一个一个痛点的实施，最后再连接成一个完整的 DevOps 交付流水线工具平台。
第二种则是从项目突破，先找一个比较典型的项目或者产品作为试点，在该项目或者产品上构建完整的工具平台，并进行深入实施，在实施成功后，再推广至其他的项目或者产品。这种方法的特点是，先考虑比较小的范围和需求，在获取到好的收益后，再考虑更广的范围和需求，对原有工具平台做优化。
当然，具体企业有具体企业的固有特点，包括文化、组织结构、现有技术水平等等，真正的实施思路还需要具体根据具体的情况进行更具个性化的制定。
实施难点及经验总结
过去的几年中，本文作者所在团队一直在某些金融企业实施本文所述的 DevOps 流水线工具平台，根据实施过程的经验，我们认为，在实施过程中，主要存在如下几大难点：
短期收益与长期收益的平衡
对于开发人员和运维人员来说，每天的工作任务都非常重，其最关心的是眼前的问题能不能解决，当前的效率能不能马上提高。而任何一个新工具，新方法的实施都不可避免地需要投入一定的时间进行学习、适应，会对当前的工作造成影响，甚至短期内反而会降低效率。故而在实施初期会引起部分团队成员的抵触和反对，这个时候，如何将开发人员及发布人员当前迫切关心的短期收益与整个平台实施后的长期收益结合起来就成为实施推进的难点之一。