瀑布开发流程与敏捷开发流程，devops概念的理解

瀑布开发流程

瀑布模型是一种经典的线性软件开发过程，按照以下步骤进行：

需求分析：收集用户需求，明确系统功能和性能要求，并编写需求规格说明书。
系统设计：根据需求规格说明书，设计系统的整体结构、模块划分、数据库设计等，并编写系统设计文档。
实现：根据系统设计文档，进行编码和单元测试，开发出软件的各个模块。
集成与测试：将各个模块集成到一起，进行系统测试、验收测试和性能测试。
部署：将经过测试的软件部署到目标环境中，进行最终的安装和配置。
维护：软件正式交付后，进行后续的维护和支持工作，包括bug修复、功能增强等。

特点和适用场景

特点：阶段性清晰，每个阶段有明确的输入和输出，适合相对稳定、需求明确的项目。
适用场景：较小规模、需求变化不频繁的项目；对时间、成本、质量管理要求严格的项目。

优缺点

优点：结构清晰，易于管理和控制；适合初期需求相对稳定的项目。
缺点：不利于应对需求变更，容易导致后期重大修改；测试和用户反馈较晚，风险难以及时发现。

总结：瀑布模型严格定义了每个节点的入口和出口要求。每到一个节点会进行严格的评审，如果达不到出口要求，下一阶段的工作就不展开。严格控制需求变更，一般来说，需求分析阶段通过了之后，需求不再变更。如果需要变更，必须经过详细的论证，并且通过严格的审批才可以变更。每个领域的分工都非常明确，每个阶段的人员只要关心自己阶段的工作，按照阶段输入输出要求完成自己的工作即可

敏捷开发流程

敏捷开发强调快速反馈和灵活性，通常采用以下方法：

制定计划：确定开发周期和优先级。
迭代开发：将整个项目分解为小的可交付的部分。
持续集成：频繁地整合代码，确保系统稳健。
客户参与：鼓励客户积极参与并反馈。
反思总结：团队根据实际情况不断调整和改进。

总结：敏捷开发会以用户需求进化为核心，用户在实际场景中发现问题并给予反馈，研发人员快速修改弥补需求中的不足，提供新的版本给用户继续使用。上述过程会不断迭代，直到用户满意。

两种开发模式对比

瀑布开发更适合需求相对稳定、较为可预测的项目，但缺乏快速变化和客户反馈的机制。
敏捷开发更适用于需求不断变化、复杂度高的项目，能够快速响应变化和加强客户参与。

总结:
瀑布开发：比如标版项目的进行，首先会花费大量时间收集和分析需求，然后进行系统设计。这个阶段可能需要以周为周期来完成，并且客户通常只能在最终交付的产品中看到结果。设计包括功能设计、技术架构设计、数据库设计等等，设计完成后，团队才开始编码，接着进入测试阶段。测试通过后，产品被部署并且开始维护。在这个过程中如果客户提出新需求，会收集需求然后出计划后续标版迭代完成，无法灵活应对客户需求，需求变更难度大。
敏捷开发：更偏向于根据客户要求来设计产品功能，弱化设计的过程，在与客户密切交流合作的基础上，通过短周期迭代交付产品，通过客户及时审查提出反馈意见，再去迭代满足客户需求，更偏向农行等定制化项目以及内部中间件项目。

DevOps概念的理解

DevOps是一种软件开发和运维文化、工具集和实践方法，旨在加强软件开发团队与运维团队之间的协作和沟通，以实现持续交付和高质量软件服务。

核心理念

自动化：通过自动化流程（如构建、测试、部署等），提高效率并减少人为错误。
协作：强调开发团队和运维团队之间的紧密合作和沟通，打破传统的"瀑布式"开发和运维模式。
持续交付：致力于不断交付高质量的软件，并快速响应用户需求和市场变化。

核心实践

持续集成：频繁地将代码集成到共享仓库，并进行自动化测试。
持续交付：通过自动化流程，实现持续交付高质量的软件。
持续部署：自动化将通过测试的代码部署到生产环境。
监控与反馈：实时监控系统运行情况，并及时反馈给开发团队。

目标和优势

加速交付：缩短软件从开发到生产的周期，提高交付频率。
降低风险：通过自动化测试、部署等，降低软件发布的风险。
增强稳定性：改善软件质量，提高系统稳定性和可靠性。
优化成本：减少重复工作、提高效率，降低成本开销。

上面都是比较概念的东西，了解下来还是不太清楚为什么会出现Devops概念，查资料下来发现一个“部门墙”的概念，Dev为开发，ops为运维，Dev的关注点是如何开发测试交付新的功能，Ops的关注点是保证应用运行的稳定和高性能，就会有墙的产生了
矛盾点产生就会有：
开发不考虑运维运营，只管开发完最基本的功能就交付，不考虑系统是否可维护；反过来，运维只关心系统的可用和稳定而不想频繁迭代。

从瀑布开发到敏捷开发实际上打破的是测试与研发之间的部门墙，但是市场变化越来越快，充满易变性、不确定性，需要更快的交付和反馈，所以只打破研发和测试的部门墙还不够，现在需要将开发和运维运营也打通，将部署环节也加入进来。那Devops实际上就是打破开发与运营之间的壁垒，将开发测试环节与部署环节结合起来。

那接下来从各个角度看下devops的实际应用
首先从人员管理角度看，开发完成后的交付物，交给运维团队负责部署、发布和运维。DevOps类似于图中，每个开发团队都有自己的运维人员（运维人员少的也会有共享的运维联络人）。

其次从工具使用的角度来看，研发交付的每个过程都离不开工具的支撑。如果各个部门搭建零散的工具系统自用，比如用来管理代码的Gitlab，各个部门自建不进行统一，就会存在2个问题，一是多个部门同时维护相同作用的Gitlab系统，人力成本更高，且更容易出现稳定性，安全问题（gitlab本身存在安全漏洞需要经常更新维护，自建很少考虑）；问题二是缺少信息共享，比如中间件部门都把代码存在自己单独的Gitlab，其他同事都不知道有这部分代码，那就会出现代码的冗余，重复开发。

还有跟着Devops同时出来的还有CI/CD，CI是Continuous Integration（持续集成），而CD对应Continuous Delivery（持续交付）或Continuous Deployment（持续部署），持续呢就是及时发现问题，及时响应。
持续集成是指多名开发者在开发不同功能代码的过程当中，可以频繁的将代码行合并到一起，然后进行自动化测试，不相互影响工作。
持续交付是指在持续集成的基础上，将集成后的代码部署到测试环境中。如果测试后没有问题，会部署到预发布环境，正式发布前的最后一次测试，环境与正式环境高度相似，预发测试后可以继续手动部署到生产环境中。
持续部署是指在持续交付的基础上，把部署到生产环境的过程自动化。