如果所有的事情都到了验收的时候才去处理，那么往往为时已晚，说得直白一点对应乙方提供给甲方的业务系统对甲方来说就是一个黑盒子，里面的东西甲方完全搞不懂，只有乙方能够进行后续运维和定制维护。也就是甲方不得不承认间接被乙方绑架的事实。
我们都知道最终的研发资产要能够移交，要能够可交维，但是里面的关键点究竟在哪里？
简单来说就是研发资产的可交付必须是一个在一开始就持续增量不间断进行的过程，一个是按阶段进行持续的交付，一个就是按业务系统的功能点进行持续集成交付。在整个过程中会分很多小的阶段点，在这些阶段点都需要植入相应的自动化检查和测试手段，确保最终入库的资产质量是满足的。整个持续集成过程在一开始配置完成后，研发人员就不应该过多地介入，而应该是流水线自动进行，确保中间没有人为不确定性因素的加入。
微服务架构和容器云推动DevOps大发展
注意，在企业没有实施容器云，微服务架构改造的时候，实际前面谈到的持续集成，部署等工作量并不大，因此企业也很少单纯为了提升交付效率而实施DevOps。
但是在实施微服务后，你会发现原来的一个大单体应用拆分为了20个微服务甚至更多，每个微服务都涉及到编译，构建，打包部署等动作。整个集成和部署的工作量就大大增加了。
因此你不得不考虑进一步将这些工作自动化掉。
比如我们采用Jekins来实现整个CI/CD过程，同时将Jeins和敏捷研发，自动化测试工具或脚本，容器云交付平台进行集成，实现整个过程的自动化。
在这里提出一个重要观点，即：
在信息技术发展过程中，当采用和实践一个新技术的时候，往往会引入新的问题，这个时候我们不会是退回原点，而是进一步应用新的方法工具来解决新问题。
DevOps实践流程
从DevOps的流程实践上看，总体来说其流程可以分为需求对接和应用设计、敏捷开发和持续测试以及最终测试和上线运维等三个阶段，其核心是由开发人员和测试人员主导的敏捷开发和持续测试阶段。借助Scrum或Kanban等工作流方法的和一系列持续构建、持续集成、持续测试以及持续发布工具，IT团队能够高效率地开发通过微服务架构解耦的程序模块， 并及时、持续地与用户方面进行对接，对各个模块的研发质量和成果进行实时把控。
在通过最终的集成和测试之后软件得以部署上线，此后开发人员能够借助应用容器化封装带来的统一环境之便，与运维人员一起对软件的运行质量进行监控、 为用户提供支持服务，并继续根据市场需求进行版本更迭的进一步开发工作。
在谈DevOps成熟度模型的时候我谈到过，简单来说DevOps最佳实践包括了三个方面的关键内容，即：
- 敏捷研发和过程管理（引入微服务开发实践）
- CI/CD(扩展持续交付 自动化测试）
- 运维管理（扩展到持续闭环技术运营）
只有围绕上面几个点，那么整个DevOps实践相对来说就是完整的。
敏捷研发和微服务
大家一定要注意，在实施微服务后对整个DevOps过程的一些影响。
