简单理解Devops

1 什么是DevOps

每一个人的回答都是千奇百怪，不知道的人回答：“是develop吗？你把开发分支单词写错了”；听说过或者知道一点的人说：“这还不简单，不就是Develop和Operation，开发与运维的合并嘛！”；还有的回答是敏捷开发工具；或者是构建部署工具链；甚至有回答说：“DevOps就是一种思想和文化理念”。

但这些回答都不全面，或者太偏。简单的回答就是构建一套完整的工具链来支撑从需求提出到需求交付，保证整个过程需求任务最小化单元，开发迭代高效，代码及构建安全，交付线上稳定，运行问题持续反馈。

2 DevOps各大板块

1

建立好DevOps简单的概念后，我们就从一个需求入手，看其是怎么从需求想法发起，到交付后持续反馈给需求提出者的。以下分几大模块级联展出：

1.需求统筹

什么是需求统筹，就是需求统一管理模块：该模块主要功能是开放给各个不同业务部门提出需求各种各样的需求，但并不是每个需求都马上到DevOps中进行迭代开发，这时候就需要需求统筹进行需求提出方进行自己的需求可行性分析和审核，保证到DevOps的需求是真正可行有用需求。并且需求提交时候可以选择流程模板选择：普通敏捷迭代，增加可选项：如性能压测。

2.需求管理

这时候需求已经进入DevOps需求管理模块，接下来的工作是产品经理或者相关负责人进行需求审核，拆分，确认，分配等。此时需求是经过业务方自行确认过的，这样可以提高需求的真实有效性。

3.迭代计划

以团队空间（推荐按照产品维度）进行需求迭代开发任务计划管理。分配需求（子需求）开发计划，整个过程联动需求任务划分，需求评审，需求就绪，需求设计，需求开发，需求测试，需求发布，需求交付，需求确认，需求验收等。

4.代码管理

代码开发与迭代计划紧密联系，关联需求任务卡片，双方可是实时查看开发进度（开发分支，开发提交内容，代码合并评审信息等）。

同时开发人员按照团队开发设计规范进行开发，包括分支规范（git-flow,gitlab-flow,Aone-flow【阿里】等多种分支模型），如：根据Aone-flow改进分支模型

5.测试管理

此处包括两部分（功能测试和自动化测试）其中功能测试：缺陷管理，用例管理，提测管理，测试计划等，同时测试人员可以在参与需求设计时候写好测试用例和冒烟用例，然后开发自行冒烟测试通过再交给测试人员进行集成测试。从而提高开发人员开发能力和减少测试人员反复测试浪费的时间。

自动化测试：接口自动化测试和UI自动化测试，也是现有相关接口测试用例，然后创建测试方案，实现完整的接口自动化回归测试。可以完整的回归测试所有接口，同时减少测试人员重复工作量。

6.持续部署CD

要想开发的代码构建后运行起来，那么就需要先将基础资源准备就绪：根据需求进行基础资源申请（CPU，内存，磁盘，域名解析等）推荐容器云，不推荐虚拟机或物理机。然后快速创建对应的产品应用，再建立对于的分组环境与资源绑定。还可以纳管外部容器云集群或者虚拟机，其中相关基础CMDB数据可以来源于基础架构数据源。

7.持续集成CI

CI实际上一系列流水线管道集成。可以包括但不限于（容器流水线）入口参数配置，下载代码，代码静态扫描，代码安全检查，代码构建，构建依赖安全检查，构建制品包存储，构建镜像，镜像安全检查，镜像存储，触发持续部署，更新部署镜像信息，软件成分分析等。

8.性能压测（可选项）

性能压测，大多是根据业务需求最初的设计而来定，不同的场景有不同的要求，企业内部系统或者并发不大的系统需求不高，但对于互联网产品或者高并发场景下性能压测必不可少，因为可以提前预判系统的性能问题和瓶颈点，做到以防为主。

9.持续反馈

持续反馈大多表示部署上线后的运行状态数据采集反馈，但这样还不够，而是需要囊括整个产品需求的生命周期，从需求设计，开发，测试，交付，运维等阶段进行实时反馈，保证问题反馈的高效性，避免浪费各个环节的资源。 真正做到全链路问题持续反馈。

10.效能度量

分不同的维度（管理层维度，研发层维度，需求方层面维度）进行度量，包括需求度量，测试度量，开发度量，持续集成度量，持续部署度量，持续反馈度量，产研周期，工时规划等模块。

11.全链路监测（环路）

从业务需求方提交后，形成一条完整的流程链路，需求方可以在需求提出地方查看当前需求走到那些环节，每个环节所涉及到的具体信息可以简要查询（如：当前何时走到开发，开发目前还在提交代码还是已经部署测试环境进行冒烟测试或者已经完成测试）给用户真正透明需求交付过程。同时用户进行评分度量时也可以清楚了解整个过程那些环节完美，那些环节不完整。

3 Flow Picture