DevOps实战50讲-(1)彻底理解DevOps

news2024/9/30 23:32:46

持续坚持原创输出，点击蓝字关注我吧

软件质量保障:所寫即所思｜一个阿里质量人对测试的所感所悟。

浅谈软件开发流程

软件开发流程是从需求分析、设计、编码、测试到上线等一系列环节的步骤和活动。通常来说，软件开发流程可以分为以下几个阶段：

需求分析：明确客户需求，收集、分析、整理、确认需求，以确保开发出的软件符合客户需求。

设计阶段：在明确的需求基础上，进行软件架构设计和详细设计，确定软件的功能模块和模块之间的关系。

编码阶段：根据设计文档进行程序编写，实现系统功能模块，通常会使用特定的编程语言和开发工具。

测试阶段：进行各种测试，包括单元测试、集成测试、系统测试等，以确保软件质量。

发布阶段：将软件发布到生产环境中，进行部署、配置、发布等操作，确保软件正常运行。

运维阶段：对软件进行监控、维护、升级和优化，以保证软件稳定运行。

不同的软件开发团队和项目可能会有不同的开发流程，例如采用敏捷开发、瀑布模型等不同的开发方法。但是，以上阶段基本上都是必不可少的（阿里研发流程知多少），软件开发流程的目标是确保开发出的软件质量、满足客户需求、按时交付并能够可靠地运行。

我的第一份工作，所在的团队当时的研发模式属于瀑布模式。它将软件开发流程分为一系列相互依赖的阶段，每个阶段必须在上一个阶段完成之后才能开始。瀑布模式存在风险管理能力不足、测试不充分等问题：

需求变更困难：瀑布模型是一个严格的阶段性过程，每个阶段必须完成后才能进入下一个阶段，这使得在项目开发过程中，客户的需求变更非常困难。

风险管理不足：由于在瀑布模型中，风险评估和管理通常在项目开始阶段进行，因此在后期发现的风险可能导致整个项目失败。

测试不充分：瀑布模型的测试阶段通常在开发完成后进行，这可能导致在测试阶段发现的问题难以解决，同时也会增加修复问题所需的时间和成本。

缺乏灵活性：瀑布模型中每个阶段的输入和输出必须按照一定的顺序执行，这意味着在需求或设计阶段出现问题时，整个项目可能需要重新开始。

周期较长：由于瀑布模型的每个阶段必须按顺序执行，因此整个项目的周期通常较长，这使得瀑布模型对于那些需要快速交付的项目不太适用。

传统的瀑布模式不适应如今的互联网大环境，而敏捷开发模型是一种迭代的、增量式的软件开发方法。它强调快速响应变化和客户需求的能力，并且通过与客户的持续协作来确保软件开发过程中的透明度和质量，目前被互联网公司广泛采用。

敏捷开发强调尽早、频繁地交付可用的工作软件，并通过快速反馈和验证来确保软件的质量和正确性。

站在测试的角度，瀑布模式下，开发完成coding提测后，测试向开发反馈BUG(沟通成本高)是一个反复且非常耗时(机械)的过程，很显然不适合敏捷开发的要求。可以参考我这篇文章《阿里微服务质量保障系列：研发环境知多少》

如果让开发和测试(运维)团队整合到一个团队，是不是可以最大限度地降低了反馈成本，DevOps也就应运而生。

我对DevOps字面意思的理解

DevOps由Development和Operations两个词组成。其中Development代表着软件开发，包括设计、编码、测试等过程；Operations则代表着软件运维，包括部署、监控、维护等过程。因此，DevOps的字面意思可以理解为将软件开发和运维整合在一起的一种方法或理念，旨在加快软件交付速度、提高软件质量和可靠性。

说的大白话些，就是“简化”开发和测试(运维)之间流程，通过工具使提升整体软件开发速度。

再说直白点，DevOps解决的根本问题就是软件开发和测试(运维)之间的分离和沟通不畅的问题。

注：为什么说DevOps既可以说开发和测试、又可以说开发和运维呢？这里说一下个人对DevOps的理解。
这主要是因为不同公司对运维这个岗位的职责和归属不同。
我的第一家公司，运维是独立的岗位，有一个人专门负责，工作内容就是服务器监控、到甲方部署软件等，即开发->测试->运维。
阿里这边运维的责任貌似更多在开发同学肩上，当然测试也会负责，但大多数时间由开发负责，因此开发即运维，这里DevOps叫做DevTest其实更合适。