多年前，当我们使用瀑布开发模式时，我们的开发流程如下：分析-设计-开发-测试-交付-运维。最终的交付只有一次，或者是有限的次数。瀑布开发模式的周期长，对于软件产品的更新迭代困难度较高。因此在软件工程中，结合精益软件的思想，专家们提出了敏捷方法（scrum）。敏捷方法不再严苛要求环节，而是更注重开发人员与业务人员的沟通交流，不断地完善产品。在敏捷方法中，软件的交付是频繁的、没有上限的。交付不再是软件工程生命周期的结束，而是持续不断的完善过程中的一个必要环节。
敏捷方法不是非常新的理论，Mike Beedle等人于2001年提出了敏捷软件开发宣言，标志着敏捷开发思想的面世。由于敏捷方法将交付环节变成一个频繁的环节，模糊了交付与运维之间的关系。即运维-更新-交付之间的无限循环，运维不再是交付之后的步骤，没有了明显的顺序关系。因此，随着敏捷方法的提出，一个重要软件工程概念形成了，那就是DevOps（Development和Operations的组合）。DevOps要解决的是传统开发模式里开发与运维的对立，或者说是各自的独立性。因为在过去，开发人员与运维人员的交互是有限的，他们工作在不同的世界中。
敏捷方法是DevOps的理论基础，DevOps是敏捷方法的具体化和实践原则。敏捷方法理论的两个核心是：持续集成与持续交付。持续集成是指不同组件、不同团队、不同平台的之间的对接和集成。而持续交付则是上文所说的将交付变为频繁、常态化的环节，在持续交付中实现对软件产品的不断完善和扩展。让我们回想瀑布开发中软件的交付前后所涉及到的几个时间节点：测试-部署-交付，在敏捷方法中，频繁的交付和部署要求将这几个环节实现自动化。而不再是运维人员将其通过人工的方式，使用命令行将软件部署到生产环境。自动化的部署要求，使得springboot框架应声而出，让我们回想springboot的目的，正是一种快发开发领域的解决方案。在数据库方面，敏捷方法也推动了MongoDB等NoSql数据库的发展，由于NoSql数据库的半结构化特点，回避了Sql数据库在改动库表结构方面的复杂性，使其在快速迭代和增量开发中十分好用。在项目构建方面，Grandle和Maven等工具减轻了项目的构建难度，使其成为敏捷开发中的重要实现手段。此外，由于持续交付对于软件版本化的要求，Git因其在分支处理的优势非常，从而也成为敏捷开发的重要工具。
但是因为在敏捷方法刚被提出时，软件的部署环境和 络制约了自动化的应用。不论是单机软件，或者是基于C/S或者B/S结构的 络软件，由于固定的软件运行环境，例如单机程序，频繁的交付很难实现；而对于企业级应用，私有的物理服务器和封闭的运行环境让持续集成和持续交付成为困难。而云的出现成为敏捷方法普及的助推力。
云提供了一种完全不同的思路。借助 络的高速发展，云让软件摆脱了私有物理服务器，云的弹性服务、资源池化、按需服务等特定让DevOps变得更为轻松。例如，通过云，只需要 络即可实现软件的部署。而云软件服务（SaaS）则让用户共享软件的更新，让每一次软件迭代轻松传达到所有用户。
借助云的优势，持续集成的各个组件可以跨语言、跨平台开发与部署，这就推动了微服务概念的提出。微服务的发展让视图和服务分离，从而推动了AngularJS和VueJs等前端数据绑定框架的出现。而将组件更细粒度化，则推动了Serverless或称为”函数计算“概念的提出。在持续交付方面，要求在开发过程中尽量模拟生产环境，因为开发过程是并行在生产过程的。而容器的轻量级封装特点，能沟保持运行环境的稳定，使其成为一种优秀的云上软件交付工具。
云、scrum互相推动，彼此促进发展，是软件工程的发展史的重要组成部分。在软件工程管理上，始终难以解决的难题是工程规模的量化分析。无论是瀑布开发还是增量开发，直到今天的敏捷开发，都是在不断的探索和实验，以求在无法精确计算工程规模的背景下尽量节省成本，提高产品质量。尽管同是设计到交付，土木工程由于其依赖技术和支撑技术的稳定性，以及用户需求的大同小异，使得工程管理及其造价有可靠经验可循。但在软件工程上，技术的快速更新迭代，使得我们难以依靠已有的经验推算未来的工作量，对软件工程的探索依旧在进行。
文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树容器编排(生产环境 k8s)kubelet,kubectl,kubeadm三件套8788 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！