DevOps解决方案

1  背景与需求分析

1.1  DevOps

DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发与运维之间相互依存关系的一种新的理解。

针对DevOps的落地,博思云为提供覆盖组织架构、流程改造、角色定义、关键动作、输出物等DevOps落地咨询服务,形成需求管理、代码架构、持续集成、自动化测试、自动化部署、验证与发布在DevOps下的流程体系。

1.2  客户痛点分析总结:

  • 周期长:客户产品/项目上线周期长的核心痛点
  • 效率低:客户团队沟通协作不统一,效率低下
  • 过程复杂:部署环境不一致,不稳定,过程复杂
  • 版本混乱:版本混乱,无法追溯

2  阶段划分

2.1  策划阶段

从产品策划这个角度来看,主要是产品经理使用;管理的工件是产品愿景、MRD(市场需求)、BRD(业务需求),以及产品间的关联关系。DevOps平台设计过程中需要关注不同产品级别的流程设计,以及提供整个企业维度的业务域的划分与管理,包括业务模块和产品线。

2.2  研发阶段

从产品研发的视角来看,研发阶段主要是给产品经理使用;管理的工件是产品版本、 PRD、里程碑、路线图等。

2.3  运营阶段

接下来是运营阶段,主要服务客服、运营团队、产品经理等角色;管理工件主要包括事件、问题、配置、服务的SLA。 PRD、里程碑、路线图等。

3  项目流程

3.1  项目立项与启动阶段

在整个项目启动和立项的时候,我们一旦把产品定义完以后,接下来就基于某个产品要做项目的开发。在项目的立项和启动阶段,最主要的是组建项目团队包括权限,提供环境的快速开通。

DevOps要提供整个团队管理的能力,提供不同的角色在平台上进行协作,分配不同的权限。

DevOps需要提供关键的流程支撑,包括对过程的选择(Scrum、传统瀑布模式等),定义对应的交付流水线。

3.2  项目需求阶段

项目需求阶段,对产品经理、项目经理和架构师来说,平台要提供基于敏捷的需求管理。

DevOps关键设计需要提供基于工作项的管理,包括需求、任务、缺陷的管理。需求变更率、任务燃尽图、积压线是重点评估的度量指标。DevOps 需要做全流程的打通,打通了以后能够给我们带来的好处是什么?可以从一个缺陷反向追溯隶属的产品版本,对应的Task,对应的需求。

3.3  项目架构阶段

DevOps 设计过程中需要提供部署拓扑图的设计,以及应用架构的设计(系统关联关系、接口定义等)。

在架构里面,最主要的是要把我们的产品关联组建拆分、以及要确定它的部署架构,包括有多少组件;有了这些设计后,DevOps 后续可以根据部署容器进行资源绑定,实现自动化部署;根据关联关系确定依赖,进行部署器的依赖管理工作。在部署设计中,提供了基于部署容器的概念,不同的部署容器可以编排依赖;在每个部署容器内部可以进行组件的编排。

3.4  项目构建阶段

构建阶段主要管理的是代码库、代码的 Review、构建定义和构建执行。

DevOps设计过程中需要提供最优的代码库使用方式,完成整个关键的构建定义、构建策略等工作。代码行、代码提交频率、构建次数/频率、构建时长、构建成功率是重点评估的度量指标。DevOps 需要的不仅仅是通过新的工具链实现快速交付,更是一种驱动优化的变革。

3.5  项目测试阶段

测试阶段主要管理的是代码质量、测试用例、测试计划、测试报告。

DevOps设计过程中需要支持多环境的自动部署、多策略的部署,提供测试团队进行快速的集成测试。

单元测试覆盖率、自动化测试比例、阶段 Bug 比例、Bug 打回率、部署成功率是重点评估的度量指标。在测试阶段,需要尽可能的对测试用例进行自动化测试,能够大幅提升测试回归的效率,产品负责人可以快速的评估产品版本的质量。

3.5  项目演练与上线阶段

预发/演练、上线阶段主要管理的是部署环境、组件实例管理、部署计划、交付物管理。

DevOps设计过程中需要支持多策略的发布,包括全新发布、蓝绿、灰度、金丝雀;应用可靠部署模式(集群、多主、主备等)。

单元测试覆盖率、自动化测试比例、阶段Bug比例、Bug打回率、部署成功率是重点评估的度量指标。

DevOps并不是自动化一切,而是在可控中有选择的自动化。