谈谈对DevOps开发模式的理解
一、开发模式的发展历史
DevOps是什么？拆分开来，Dev是development，代表开发；Ops是operation，代表运维；两者结合是一个什么样的概念，带着疑问一起梳理一下DevOps的演进历史。
1、瀑布开发
背景：
在互联网初期，程序员还是科学家一样的存在，程序员的办公室还被称作实验室。当时的网民，也还没有那么多，大多数时候，他们都是带着敬畏之心提需求的。并且开发出来的产品，只要能解决他们的问题，他们都是争先恐后地给程序员烧高香、送锦旗，对研发周期，自然不敢有太多的要求，需求也自然是不变的。
在这种大背景下，1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模式。
定义：
瀑布开发模式：是按工序将软件生命周期划分为 自上而下、相互衔接的不同的阶段，如同瀑布流水，逐级下落，如下所示：
立项 --> 需求分析 --> 软件设计 --> 开发 --> 测试 --> 运维
瀑布开发的特点
- 把软件项目的开发过程分成各个不同阶段，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。
- 重视和强调过程文档，各个阶段产生的管理文档(计划书，进度表)等，能让人了解项目的进展情况
- 完成所有功能再进行交付，开发周期较长，过程中没有迭代与反馈，不能灵活适应客户需求的变化。
瀑布开发使用场景
- 需求在规划和分析阶段就已确定，且项目开发周期内需求没有或极少变化，对需求变更进行严格控制，例如航空航天、金融核心系统等；
- 稳定的低风险项目（对目标、环境非常熟悉），规模小实现简单易受控的项目；
- 合同式的合作方式，严格按照说明执行，客户需求明确且不参与软件实现过程。
————————————————
版权声明：本文为CSDN博主「PingCode丨智能化研发管理工具」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_44280696/article/details/124395603
瀑布开发的弊端
- 开发周期长，需求不能快速得到交付
- 需求变更代价极大，不能灵活适应快速变化的需求
2、敏捷开发
背景
随着时代的发展，互联网的网民越来越多，而且这些网民的要求也越来越高了。搞出来的产品，只是“能用”，已经满足不了他们的需求，更多的网民越来越追求“好用”以及“好看”。
这些人也变得越来越“朝三暮四”了，可能今天觉得这个好，明天就觉得那个好了，软件开发的周期，也被压缩的越来越短。在时代的大背景下，总有那么几个脑子进化地比较快，于是乎，敏捷开发模式从1990年代开始逐渐引起广泛关注，登上了历史的舞台：
定义：
敏捷开发模式：是一种迭代增量式开发模式，每次迭代只设计和实现软件的一部分，逐步完成整个软件的开发，弥补了瀑布开发方式中的一些弱点，具有更高的成功率和生产率。
整个软件生命周期的过程中，敏捷开发的阶段划分和瀑布开发的流程差不多，只不过敏捷开发是增量快速迭代开发，整个过程在上线（运维阶段）之前都能灵活的应对需求变更。
立项 --> 需求分析 --> 软件设计 --> 开发 --> 测试 --> 开发 --> 测试 --> 运维
敏捷开发的特点
- 80/20原则：采用迭代方式进行增量开发，可以先完成具有80%价值的20%的业务功能，进行多次迭代直至完成完整产品交付
- 快速交付：迭代周期短，产品被更快地交付到用户手中
- 灵活响应：团队可以更快地得到业务/用户的反馈，当需求发生变化的时候，敏捷开发可以及时的做出响应
- 强调程序员团队面对面的沟通和紧密协作，且目标统一，都是为了能够更快更好地开发出产品而共同努力
十二条敏捷宣言：
- 我们的首要任务是通过尽早地、持续地交付可评价的软件来使客户满意。
- 乐于接受需求变更，即使是在开发后期也应如此。敏捷过程能够驾驭变化，从而为客户赢得竞争优势。
- 频繁交付可使用的软件，交付间隔越短越好，可以从几个星期到几个月。
- 在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。
- 围绕那些有推动力的人们来构建项目。给予他们所需的环境和支持，并且信任他们能够把工作完成好。
- 与开发团队以及在开发团队内部最快速、有效的传递信息的方法就是，面对面的交谈。
- 可使用的软件是进度的主要衡量指标。
- 敏捷过程提倡可持续发展。出资人、开发人员以及使用者应该总是共同维持稳定的开发速度。
- 为了增强敏捷能力，应持续关注技术上的杰出成果和良好的设计。
- 简洁——最大化不必要工作量的艺术——是至关重要的。
- 最好的架构、需求和设计都源自自我组织的团队。
- 团队应该定期反思如何能变得更有战斗力，然后相应地转变并调整其行为。
敏捷开发的弊端
1、敏捷开发虽然提升了开发环节的开发效率和版本更新速度，但与运维的立场矛盾
虽然敏捷开发大幅提升了软件开发的效率和版本更新的速度，但是它的效果仅限于开发环节。我们发现，运维那边，非常落后的手动部署上线，就成了新的瓶颈。
运维工程师，和开发工程师有着完全不同的立场。运维团队的座右铭，很简单，就是“稳定压倒一切”。运维的核心诉求，就是不出问题。什么情况下最容易出问题？发生改变的时候最容易出问题。所以说，运维非常排斥“改变”。
于是乎，矛盾就在两者之间集中爆发了。这个时候，神秘的主角DevOps，隆重登场了。
3、DevOps开发
背景
到了当今时代，互联网的网民在海量增加，在这种背景下，诞生了众多的互联网大厂，以及多款现象级产品，比如微信、淘宝、抖音等等，互联网的竞争也越来越激烈。快速迭代产品，快速占领市场，快速占据用户心智成为了各互联网公司的目标。
这个时候，就对产品开发提出了更高的要求，需要能够对产品持续开发、持续集成、持续测试、持续部署、持续监控，需要每天每时每刻都可进行新版本的上线。
当今的互联网大厂普遍都有采用分布式微服务架构，把项目拆分成多个服务单独部署；频繁的发版上线，运维的工作变得繁重，可不堪言。
这样开发团队与运维的矛盾，是时候环节一下了，怎么缓解呢？那就把它们也搞到同一战线吧：
定义：
DevOps开发：是一组过程、方法与系统的统称（一种工程模式），用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合，对构建软件的所有环节 (从开发、集成、测试、部署和基础架构管理) 进行全面的自动化和监控。
DevOps开发模式的流程：
计划（需求） --> 编码（开发） --> 构建 --> 测试 --> 发布 --> 部署 --> 运维
DevOps开发的特点：
1、解决开发与运维之间的矛盾，提供更快的交付速度：个人理解，DevOps开发是基于敏捷开发的基础上，改善开发和运维团队之间的矛盾，把开发、测试、运维都拉到了同一战线，产品交付速度得到进一步的提升。
2、自动化贯穿整个DevOps的整个流程，包括构建自动化，测试自动化、部署自动化、运维自动化。（就是能用代码自动完成的事情就绝不要手动解决，但不是所有都是自动化）
DevOps的三大支柱：
DevOps 的三大支柱：即人（People）、流程（Process）和平台（Platform）。
- 人 + 流程 = 文化
- 流程 + 平台 = 工具
- 平台 + 人 = 赋能
devops实现相关工具
项目管理（PM）：jira。运营可以上去提问题，可以看到各个问题的完整的工作流，待解决未解决等；
代码管理：github，进行代码管理，上线，回滚等；
CI/CD：Jenkins
容器：Docker
编排：Kubernetes
服务治理：Consul。
日志管理：ELKB。
系统监控：Prometheus。
负载均衡：Nginx。
网关：Kong，zuul。
链路追踪：Zipkin。
产品和UI图：蓝湖。
公司内部文档：Confluence。
————————————————
版权声明：本文为CSDN博主「小龙飞2」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_40898368/article/details/114254930
二、DevOps的参考文章
后面补充
CI/CD到底是什么？看完就能很快理解_kele_baba的博客-CSDN博客_ci/cd
知乎的
你知道什么是CI/CD吗？不懂？五分钟让你彻底理解！ - 知乎
今日头条的
今日头条- 敏捷迭代已过时，现在大厂都在用DevOps开发模式 - 今日头条