一个传统的单体应用你要走CI/CD相当来说很容易，但是传统单体应用以及拆分为上10个甚至更多的微服务，这个时候你需要考虑。
你最终交付的是整个产品或应用，但是一个项目版本或变更过来，实际只变化了里面的3个微服务，那么如何仅仅交付和变更这三个微服务。
其次你还需要考虑，在进行持续集成的时候，不是单个微服务的编译构建，打包部署，这里面还涉及到独立的多个微服务间的横向集成，这个集成能否在DevOps过程中一并考虑到。(注：实际这块涉及到传统CMMI里面讲的PI产品集成的内容）。
为了实现这些，你可以看到产品，项目，项目版本，团队，团队成员，应用，微服务，API接口这些对象之间的关系变复杂了，需要梳理清楚这些对象之间的关系才能够构建完整的底层业务对象模型，同时需要实施类似多流水线设计等才能够满足以上业务场景。
这些内容在传统的DevOps技术工具链中不会谈到，而你在实施微服务和敏捷研发的最佳实践中一定会出现。也正是因为这个原因，我一直在强调。DevOps的核心是敏捷研发 持续集成交付的最佳实践，而非简单工具或技术的集成。
敏捷体现的一个关键点-环境迁移
实际我多次强调，DevOps在实现持续集成和持续交付过程中，有一个关键点就是环境迁移能力，即基于镜像文件和二进制包文件的快速迁移能力。
比如对于SIT测试通过的软件产品，我们可以做到一键将其迁移和部署到UAT测试环境供用户进行UAT验收测试，同时对于UAT测试通过的版本我们也可以一键迁移和交付到公有云服务平台。
这个不仅仅是敏捷交付效率，更加重要的是迁移过程不再重新编译构建，确保测试完成的内容就是最终交付的内容。
持续集成，持续部署，持续交付
这三个概念实际很多时候并没有区分太清楚，个人进一步说明为持续集成过程一定涉及到重新的编译构建，打包部署。而持续部署过程可以不涉及重新编译构建，仅仅是打包部署。持续部署可以是SIT环境到UAT，也可以是UAT到生产。而对于持续交付一般特制整个应用向生产环境和最终用户交付的过程，也就是用户最终使用到新的版本才完成交付动作。
DevOps落地实施路径
在报告中给出了一个DevOps从资源整合到自动化逐步实施DevOps的落地实施路径。
一般而言，企业实现DevOps的落地需要经历五个阶段，首先要实现企业内部的资源整合，提高资产和任务的可见性；其次是构建统一、流畅的线上和线下工作环境及流程，接着要搭建能够有效合作的团队体系，加强资源的共享；然后借助一 系列信息化的DevOps工具构建企业的自动化开发运维流水线，并生成相应的管理指标体系；自动化水平发展到一定水平 并且累计了充足的服务经验后，运维侧即能以标准化的形式为用户提供更高效便捷的服务。
对于DevOps实施，我更偏向于是整个云原生和微服务架构转型过程中的一个配套。即DevOps是配合容器云，微服务架构实施过程中的一个关键支撑过程。
如果按照这个思路，那么DevOps实施可以分为三个大阶段
- 迭代一：CI/CD 微服务敏捷研发 容器云
- 迭代二：实施自动化测试等核心过程管控
- 迭代三：实施自动化运维和AIOps能力
对于迭代一种涉及到的CI/CD，微服务和敏捷研发过程管理，容器云，从远行科技实施DevOps经验来看一起实施是更好的做法。而对于自动化测试，自动化运维等则可以放到后续阶段进行实施。
DevOps应用行业和场景
在报告里面分传统行业和科技行业对DevOps应用行业和场景进行了说明。
