系统分析与设计 课件 第七章 面向DevOps的系统开发

第七章面向DevOps的系统开发本章以华为软件开发生产线（CodeArts）为例介绍了支撑DevOps实践的工具链，以及CodeArts在软件开发流程的各个环节的工作原理和操作方式，详细阐述了需求规划与管理、开发与集成、测试管理和部署与交付的实施过程，并介绍了所涉及工具的具体操作步骤。关于DevOps的具体内容，详见教材1.5节。述本章概通过本章的学习，期望具备DevOps的实践能力，包括理解DevOps的流程和操作实践：理解基于用户故事的需求规划与管理；理解代码托管和代码版本管理的基本逻辑，熟悉主流的版本管理工具；理解代码编译构建过程，熟悉主流的编译构建工具；了解测试管理的基本流程，掌握测试案例的设计；理解流水线的工作原理及作用；理解基于配置管理、自动化和云建立的CodeArts平台的工作模式，熟悉需求管理、代码托管、代码检查、编译构建、测试、流水线等工具的操作。学习目标学习导图目录contents0102030405软件开发生产线需求管理开发与集成测试管理部署与交付软件开发生产线017.1软件开发生产线软件开发生产线（CodeArts）是华为面向开发者提供的一站式云端DevOps平台，贯穿需求下发、代码提交与构建、测试与验证、部署与运维全过程，打通软件交付的完整路径，提供软件研发托管运维端到端支持。如图7.1所示，软件开发生产线主要包含需求管理、代码托管、云集成开发环境（CodeArtsIDEOnline）、代码检查、编译构建、制品仓库、部署、测试计划、流水线等服务。需求管理027.2需求管理需求管理主要包含需求决策、需求分解、需求规划等方面。根据事物理解和分析规律，将需求分为宏观、中观和微观三个层次，在需求管理中一般对应原始需求、特性和故事三种具体表示(如左图)。本节通过介绍思维导图、甘特图、特性树等工具对需求规划的理念和实践方法进行阐述，详细操作请参考华为需求管理用户指南。7.2.1需求决策原始需求（RR）是来自企业内部和外部客户以客户视角描述的原始诉求。原始需求要经需求分析团队分析评审后决定是否接纳，其过程包含收集、分析、决策、实现和验收五个阶段，如下图。第一步原始需求的收集第二步原始需求的分析第三步原始需求的决策第四步原始需求的实现第五步原始需求的验收7.2.1需求决策1.原始需求的收集针对客户痛点、应用场景等信息，通过主动或被动的方式进行原始需求的收集。例如针对“凤凰商城”用户收集图片管理、数据统计等原始需求（如下表）。编号描述1【客户声音】希望凤凰商城能够支持商品图片管理。2【客户声音】希望凤凰商城的数据统计更智能化。3【客户声音】希望凤凰商城能增加重要信息的推送功能。4【客户声音】希望凤凰商城能支持商品数据的导出。2.原始需求的分析从各渠道收集来的原始需求往往存在笼统、模糊等问题，需要进行提炼，并以规范的语言描述。提炼后的需求应当达到可度量、可验证的程度。经需求分析团队分析后，提炼后的需求依据需求价值进行排序，通过需求的“性价比”大小来判断需求是否接纳（如下图）。7.2.1需求决策3.原始需求的决策原始需求的决策以分析结论为重要参考依据，决策结论要明确、可执行。如右图所示，决策要素通常包括：交付时间、交付的需求范围以及其他重要说明事项。7.2.1需求决策4.原始需求的实现需求实现的过程就是根据开发流程产出结果对原始需求状态进行更新。如右图所示，原始需求分解的用户故事（US）全部完成，则需求自动流转至下一状态。同时，需求实现要开展严谨的需求实现跟踪，以保证需求理解不会出现偏差，避免出现无法达成客户承诺和期望的情况。7.2.1需求决策5.原始需求的验收原始需求的验收由提交人代表客户来进行的。提交人通过评审测试报告、需求报告等方式开展验收流程7.2.2需求分解EpicFeatureStoryTask原始需求通常是抽象和宏观的，需要理解客户需求背后的问题本质，需要把原始需求进行规划和分解，最终分解为每个迭代可交付的最小工作项。CodeArts的Scrum项目模板采用“Epic>Feature>Story>Task”四层需求模型，从原始抽象宏观的需求Epic（战略举措），经过分解为多个Feature（特性），继而再逐步分解为Story（故事）和Task（任务）。7.2.2需求分解Epic通常翻译为史诗，指公司的关键战略举措，可以是重大的业务方向，也可以是重大的技术演进。企业通过对Epic的发现、定义、投资和管理，使企业的战略投资主题得以落地，并获得相应的市场地位和回报。Epic的粒度比较大，需要分解为Feature，并通过Feature继续分解细化为用户故事来完成最终的开发和交付。Epic通常持续数月，需要多个迭代才能完成最终的交付。Epic应该对所有研发人员可见，这样可以让研发人员了解交付的Story承载怎样的战略举措，让研发人员能更好地理解其工作的价值。Epic通常和公司的经营、竞争力和市场环境等因素紧密相关，Epic描述举例如教材表7.2所示。Epic7.2.2需求分解Feature代表可以给客户带来价值的产品功能或特性。Feature向上承接Epic，向下分解为Story。相比Epic，Feature更具体形象，客户可以直接感知，通常在产品发布时作为ReleaseNotes的一部分发布给客户。Feature通常持续数个星期，需要多个迭代完成交付。Feature应该对客户都有实际的价值，特性的描述通常需要说明对客户的价值，这与产品的形态、交付模式有关。Feature的描述方式一般采用“用户<角色>…希望<结果>…以便于<目的>”模板，Feature描述举例如教材中表7.3所示，列举了四个特性描述案例。Feature7.2.2需求分解Story是UserStory（用户故事）的简称，是从用户角度对产品需求的详细描述。Story承接Feature，并放入有优先级的backlog中，持续规划、滚动调整优先级，始终让高优先级的Story更早的交付给客户。Story应遵循如下的INVEST原则：Independent：每个用户故事应该是独立的，可独立交付给客户。Negotiable：不必非常明确的阐述功能，细节应带到开发阶段跟程序员、客户来共同商议。Valuable：对客户有价值。Estimable:能估计出工作量。Small：要小一点，但不是越小越好，至少在一个迭代中能完成。Testable：可测试。Story的描述也采用“用户<角色>…希望<结果>…以便于<目的>”模板，例如教材中表7.4的案例。Story7.2.2需求分解在迭代计划会议中，将纳入迭代的Story指派给具体成员，并分解成一个或多个Task，填写“预计工时”。如教材表7.5所示，Task的描述中明确了处理具体任务的人员。Task分解后的需求对应一个工作项，在CodeArts平台上，形式上以工作项为基本单元进行开发流程管理，可以在工作项页面填写详细的信息，例如描述信息、处理人、优先级、重要程度、父工作项、附件等（如右图所示）CodeArts工作项页面7.2.3需求规划:思维导图在Scrum项目过程中，需求分解准备好后，通过思维导图进行规划，将工作项的层级结构展示出来，以便更直观地展示父子关系。下面将介绍CodeArts平台上如何创建和管理思维导图：创建思维导图。如教材中图7.8所示，首先进入项目界面，选择“规划”栏，点击“思维导图规划”创建并命名。如教材图7.9所示，进入思维导图界面后，每个节点下面有“删除”、“添加兄弟节点”和“添加子节点”三个节点管理功能。批量添加工作项。可以直接通过“添加Epic”功能将所有Epic下的工作项导入到思维导图中（教材图7.10）。

详细操作步骤参考教材。凤凰商城示例见书中表7.67.2.3需求规划:甘特图甘特图是除思维导图外另一种常用的需求规划工具，也被称为条形进度表，以图示通过活动列表和时间刻度表示出特定项目顺序与持续时间。甘特图中，横轴表示时间（里程碑），纵轴表示要安排的活动（工作项），线条表示期间计划和实际完成情况，可以直观呈现工作项的时间规划、项目进展，便于管理者弄清项目的剩余任务，评估工作进度。在甘特图中，可根据实际情况灵活添加“里程碑”，同时工作项支持添加已有工作项和新建。如右图，创建甘特图后，可以通过“添加已有工作项”将之前创建的“商城管理”Epic导入进来，根据实际需求修改每个工作项的时间信息，形成“商城管理”甘特图。更多信息见教材图7.14、图7.15开发与集成037.3开发与集成持续开发与集成主要体现在迭代开发、代码检查和编译构建三个方面。右图为持续开发和集成流程7.3.1版本管理版本控制系统是软件版本管理的主要工具，本质是保存文件多个版本的一种机制。当修改某个文件后，仍旧可以访问该文件之前的任意一个修订版本，版本管理也是我们共同合作交付软件时所使用的一种机制。如左图所示，本节以华为代码托管服务（CodeArtsRepo）为例介绍代码托管和版本管理流程，其流程包含环境准备、日常开发和合并评审三个大的步骤。7.3.1版本管理：流程第一步创建代码仓库第二步设置密钥与密码第三步分支管理第四步代码开发创建代码仓库、设置密钥与密码具体细节详见教材7.3.17.3.1版本管理：分支管理分支是版本管理工具中最常用的一种管理手段，使用分支可以把项目开发中的几项工作彼此隔离开来使其互不影响。以”Git-Flow”工作模式为例（如左图所示），核心分支(master)是仓库的主分支，用于归档历史版本，包含最近发布到生产环境的代码，该分支只能从其他分支（例如release或hotfix）合并，不能在这个分支直接修改‌。开发分支(develop)是用于平时开发的主分支，应永远是功能最新最全的分支，一般由功能分支或上一版本的发布分支合入。功能分支(feature)用于开发某个新功能，可以几条并行存在，每条对应一个或一组新功能。发布分支(release)用于检出某个要发布的版本，当需要发布一个版本时，被开发分支合入。当生产环境发现新的BUG时候，我们需要基于核心分支创建一个补丁分支(hotfix)，在该分支上修复BUG，完成后，再把补丁分支合并回核心分支和开发分支。‌7.3.1版本管理：代码开发日常代码开发一般包括推送架构代码、克隆代码、代码提交和分支操作等步骤。仓库创建之初需要先推送架构代码，然后在此基础上建立分支进行增量开发。架构代码的推送可以通过Git客户端，步骤如右图第一步打开本地框架代码所在根目录，确保根目录名与云端创建的代码仓库名一致，在根目录下右键打开GitBash终端第二步推送代码到云端。在当前GitBash终端依次输入如教材中表7.8所示命令7.3.1版本管理：代码开发当云端代码准备好后，开发人员可以在本地克隆云端代码仓库。具体操作为在克隆代码的目标文件夹下右键打开Gitbash终端，输入克隆命令：$gitclone仓库地址一次修改被成功提交到远端仓库会历经四个区域：“本地工作区→缓存区→版本库→远端版本库”。通过执行相应的Git命令，文件在这四个区域跳转，并呈现不同的状态，如右图。代码提交主要涉及add、commit和push三个操作，如表7.97.3.1版本管理：代码开发在代码开发过程中需要进行分支操作对工作进行切分，使开发人员能够方便地切换到不同开发环境中工作。Git分支的创建不是复制版本库的内容，仅仅是新建了一个指针，指向最后一次提交。分支操作主要涉及的命令如表7.10所示。7.3.2代码检查代码检查代码检查主要包含准备工作、任务创建、规则集设置、任务设置、任务执行和检查结果查看等步骤。准备工作主要包括项目创建、代码仓库创建、代码准备等工作。任务可以针对不同的源码进行创建，包括GitHub、码云Git、Repo等。对于CodeArts平台代码检查1.首先要创建检查任务，设置对应的代码仓库和分支（例如master）。然后在规则集中选择对应的语言，并配置规则.2.启动代码检查任务，当页面提示“分支最近一次检查成功！”，表示任务执行成功。代码检查服务提供检查结果统计（见教材图7.30），并对检查出的问题提供修改建议，可以根据修改建议优化项目代码。7.3.3编译构建编译构建是持续集成的一个核心步骤，支持灵活地构建软件包进行发布。CodeArts平台的编译构建服务（CodeArtsBuild）提供配置简单的混合语言构建平台，支持任务一键创建、配置和执行，实现获取代码、构建、打包等活动自动化。如右图所示，创建并下发构建任务后代码仓库代码和依赖包将被拉取到编译构建环境中生成对应的软件包到版本库中。7.3.3编译构建如右图所示，编译构建的基本操作流程包括新建任务、执行任务和查看结果三个主要步骤。更多步骤与细节参考教材测试管理047.4.1基础操作本节以华为测试工具TestPlan为例介绍如何使用测试服务管理项目的测试周期，包括创建测试计划、执行测试计划和测试进度跟踪三个方面。在管理项目规划步骤确定迭代计划后，测试人员即可在开发人员进行代码开发的同时编写测试用例。测试具体步骤如下第一步新建测试计划后，进入测试案例设计界面，选择对应的测试计划，选择需求目录中的需求点新建测试用例（教材图7.39）。第二步在测试用例界面填写名称、执行方式、描述、前置条件和测试步骤等信息（教材图7.40）。第三步执行测试计划和测试进度跟踪，详细流程见教材图7.41、图7.42、图7.43、图7.44、图7.457.4.2测试设计缺陷越早发现，修复成本越低。因此，如何提升测试的完备性，提前拦截产品缺陷，是企业产品质量面临的TOP级问题。针对这一研发痛点，华为TestPlan提供了多维度测试策略和设计工具。如右图所示，借助思维导图可以进行启发式测试设计并可视化承载设计过程，根据设计输入的不同，分为“需求>场景>测试点>用例”与“特性>场景>测试点>用例”两种流程，最终输出测试方案和测试用例。7.4.3自动化测试接口自动化用例包含用例基本信息和脚本两部分。基本信息用于管理和描述测试用例，包含名称（必填）、编号、标签、用例等级、处理者、归属目录、描述、前置条件、测试步骤、预期结果。脚本定义自动化测试步骤，包含测试步骤、逻辑控制、测试参数。如教材中图7.47所示，与手动测试用例不同的是在用例信息创建界面要选择“接口自动化”自动化测试用例创建后编辑测试脚本，如书中图7.48所示，编写一个以“GET”方式访问功能接口的脚本，填写接口地址、参数、请求头等信息。部署与交付057.5部署与交付持续交付（Continuousdelivery,CD）是指，所有开发人员都在主干上进行小批量工作，或者在短时间存在的特性分支上工作，并且定期向主干合并，同时始终让主干保持可发布状态，并能做到在正常的工作时段里按需进行一键式发布。开发人员在引入任何回归错误时（包括缺陷、性能问题、安全问题、可用性问题等），都能快速得到反馈。一旦发现这类问题，就立即加以解决，从而保持主干始终处于可部署状态。持续交付是持续集成的延伸，将集成后的代码部署到类生产环境，确保可以用可持续的方式快速向客户发布新的更改。如果代码没有问题，可以继续手动部署到生产环境中。7.5部署与交付从理论上讲，通过持续交付，可以决定每日、每周、每两周发布一次，或者满足业务需求的任何频率。在Scrum敏捷开发流程中，通过迭代（或称冲刺）的方式持续交付，从用户需求到用户反馈实现每一个闭环的软件开发过程。通过最重要的迭代计划会议、每日站会、迭代回顾、验收会议来进行简单高效的管理。右图为迭代与持续交付流程7.5部署与交付持续部署（Continuousdeployment,CD）是指，在持续交付的基础上，由开发人员或运维人员自助式的定期向生产环境部署优质的构建版本，这通常意味着每天每人至少做一次生产环境部署，甚至每当开发人员提交代码变更时，就触发一次自动化部署。持续交付是持续部署的前提，就像持续集成是持续交付的前提条件一样。持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。持续部署更适用于交付线上的Web服务，而持续交付适用于几乎任何对质量、交付速度和结果的可预测性有要求的低风险部署和发布场景，包括嵌入式系统、商用现货产品和移动应用。这意味着除了自动化测试之外，还可以自动完成发布过程，并且可