一键部署
容器化技术通过打包机制和自动化编译发布能力，解决了单个服务部署麻烦的问题。服务在不同的开发、生产环境下再也不用因为环境不一致而头疼。
服务一次打包，合理编排即可随处运行，极大地提高了部署效率，几乎可以做到一键部署。
混合编排
应用服务之间需要拼装才能自由组合。容器化技术给混合编排提供了可能，借助k8s的能力，服务的发布和编排变成了一个个yml文件的简单配置。
DevOps如果从字面上来理解就是Dev（开发人员）+Ops（运维人员），开发和运维不再是分开的两个团队，而是你中有我，我中有你的一个团队。实际上，它是一组过程、方法与系统的统称。
首先，组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和测试部门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计。
其次，自动化是指所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代。
再次，DevOps的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。
总之，DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。在内部沟通上，你可以想象DevOps是一个敏捷思维，是一个沟通的文化。当运营和研发有良好的沟通效率，才可以有更大的生产力。如果你的自动化程度够高，可以自主可控，工作负担降低，DevOps能够带来更好的工作文化、更高的工作效率。
持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用，换句话说，持续交付就是不误时开发，用小步快跑的方式，打破瀑布式开发流程的拖延。要做到这点非常非常难。
首先我们要理解整个软件的开发模式（具体详见我之前的一篇文章《软件开发模式：瀑布与敏捷》）
有了软件开发模式的知识储备，我们知道了什么是敏捷开发模式，什么是每日站会，敏捷团队人员数量控制等等。我们再回头看下如何做得持续交付？
交付的速度要高速度，还要高可用，这怎么落地？为此，我这边还要一个一个概念要分享叫MVP（最小可行性产品），这是产品经理耳熟能详的。
我把他翻译成白话一点并举个场景的案例：加入我要一辆特斯拉智能电动车，我不会一下子给你在某个时间点交付整车。我会在前期设计一张核心蓝图，交付的过程类似分期付款，我先根据任务的优先级顺序，把最重要最紧急的任务，比如发动机花一个月时间造好了交付给你；接下来根据优先级队列，我可能会取出排在第二的任务，比如说轮胎，再花一周时间造好了给你。直到整个任务池的任务全部完成为止。
因此，持续交付的优势在于:
它可以缩小开发者认知，重新确认开发方向；
同时可用让这些任务并行开发，甚至采用7*24小时的开发机制，两班倒(通常游戏开发就是这么玩的)
如果中间发现问题，因为船小好调头，修修改改也就特别快了。