云效使用方式

本文主要介绍阿里云 “云效” 的使用方式, 其中包括基本概念, 需求, 任务, 代码库, 流水线等使用方式

基本概念

首先我们得先了解, 云效是什么东西, 它是干什么的

云效是一个Devops平台, 简单来说, 就是软件 需求规划/项目跟踪/持续集成/持续交付 平台

通过平台提供的功能, 我们可以对一个项目的生命周期进行管理, 从项目的开始, 直至项目结束, 全程依靠该平台来对我们的项目进行需求, 任务, 测试, bug, 自动化部署, 持续交付等

我们来想象这么一个场景, 假设我有一份后台代码, 由于后台需要进行集群搭建, 那么我们的这个后台项目就必须跑在每一台机器上.

假设我公司有1000台服务器, 难道你要手动去一台一台的 复制文件 -> 安装依赖 -> 执行 吗?

这是一件很费时费力的事情, 某人可能会说, 不是有docker吗?

docker在这里起不到什么作用, 你还不是得一台一台机器的去 pull docker && docker run ?

devops平台的作用就是: 帮你托管代码，管理项目的各个环节下的生命周期，并且，在你push代码到云效codeup, GitHub, Gitee, GitLab 等代码库时, 它会自动帮你执行一系列操作，如静态代码检查, 自动拉取代码，自动测试, 自动构建, 自动安装项目依赖, 自动运行项目

其实最主要的还是在项目管理上提供了比较大的便利，对管理人员来说，能够清晰的审阅项目的进展情况，对开发者来说，只需要关心代码开发上的事情，不必花费过多精力在服务器构建和部署上，对产品和测试人员来说，可以方便管理自己的过程文档，记录版本的变化

名词

在云效中, 我们不可避免的会遇到一些不明所以的词汇, 在这里我们来对它们做一个解释

名词	解释
需求	我们的产品, 需要有什么功能 (这个功能还没有开始做, 处于设计阶段)
迭代	产品每一次优化, 更新的过程需求, 当一个产品上线后, 一般都会有后期的优化计划, 每一次的版本更新, 就是一次迭代
任务	与代码有关, 指代码开发的任务, 根据需求完成代码开发的任务, 比如我有2个任务, 一个是完成登录页面开发, 一个是完成注册页面开发
代码	代码库, 在云效中简称 codeup, 存储代码的地方
缺陷	提交bug的地方, 当测试人员发现产品中的某个bug后, 必须主动提交缺陷, 详细描写bug产生的步骤, 造成的后果
测试计划	软件测试人员在此管理自己的测试用例
流水线	当你在本地push代码到远程代码库时, CI/CD需要执行的一系列自动化操作

需求

一个产品, 需要包含什么功能, 需要有怎样的交互, 产品外观定义, 这些都可以理解为需求.

需求通常是由产品经理所提出的.

我们在云效中, 创建需求的步骤如下:

在需求面板, 找到创建需求的选项

创建需求需要填写的主要字段如下

输入本需求的标题, 其实也就是一个标题
执行者, 代表由谁来完成这个需求
开始时间和结束时间, 代表该需求从创建, 直至完成需求, 所需要的时间
迭代, 假如没有迭代的话可留空, 如果本需求是迭代需求, 则需选择迭代, 便于项目跟踪
备注, 详细描述你这个需求的内容
优先级, 根据本需求的紧急程度进行判断与选择
需求分类, 不固定, 常见的有功能需求, 业务需求
标签, 用处不大

任务状态

在云效中, 需求的任务状态有好几种, 主要的选法如下:

当需求创建时, 待处理
执行人领取需求后, 根据需求类型进行判断任务状态
- 如果本需求涉及代码开发, 则选择 开发中
- 如果需求涉及的是理论或学习的内容, 则选择 评审中
- 其它的根据情况选择就好了
当一个需求完成之后, 执行者需要主动将任务状态切换为 已完成

迭代

迭代就是当一个项目上线后, 后期每一次更新的主要内容, 举个栗子

我们的手机系统, 每一次更新, 都可以理解为一次迭代

本次更新内容:
1. 新增了xxx功能
2. 优化了xxx功能
3. 修复了xxx功能
4. 变更了xxx协议
...

从上面这个描述也能看出, 一次迭代, 可能会包含很多更新的内容

也就是说, 一个迭代, 有可能会包含N个需求

创建迭代

在云效中创建迭代的方式如下

在页面左侧找到迭代面板, 点击加号

填写以下信息

迭代名称, 比如 1.0.1 个人中心改造, 当然, 名称如何取, 就仁者见仁, 智者见智了
执行者, 谁负责完成这个迭代的主要内容
周期和时间, 迭代的持续时间, 也就是开始到结束的时间周期
描述, 对这个迭代做一个简要的介绍描述

任务

任务与需求略微有点相似, 但 任务与代码是相关联的

我们创建一个任务, 一般代指要求某人去开发或完善某功能, 这涉及到了代码层面的操作

例如我创建一个任务, 任务的内容是指派某人去完成登陆页面的开发

一个任务的生命周期如下:

待处理, 任务刚创建, 执行人还没有领取
开发中, 执行人领取任务后, 进入到了本任务的开发工作中
评审中, 执行人完成了本任务的代码开发, 代码已提交到了代码库中, 项目负责人开始审核执行人所提交的代码
集成测试, 由测试人员执行, 确保本任务加入之后, 没有引起其他地方的错误
预发布, 项目发布前的过度时间, 用于对项目进行查漏补缺, 确保万无一失
灰度发布, 灰, 代表黑与白之间的平衡, 当产品加入了一个新功能时, 由于功能改动较大, 需要分批推送给用户, 不能一次性直接上线, 其实也就让用户参与内测, 内测过程中没有问题, 投诉, 反馈了, 再上线正式版
发布中, 这个就没啥可说的了, 产品的正式版发布

创建任务

在云效中创建任务的方式如下

在任务面板中, 从左边找到一个大大的加号

然后填写相关的任务内容, 其实这里填写的跟需求是一样的

缺陷

所谓的缺陷, 其实就是 bug

软件测试人员在例行测试过程中, 如果发现了某个bug问题, 则需要提交缺陷, 让软件开发人员跟进并修复bug

缺陷类型

缺陷通常有以下类型, 我们在创建缺陷时, 可以按需选择即可

缺陷	描述
系统缺陷	系统无法正常工作；无法执行重要功能；系统崩溃；资源不足等；如：死循环；页面崩溃
数据缺陷	数据计算错误；数据的输入输出错误；
数据库缺陷	死锁；连接错误；约束错误；表结构不合理等
接口缺陷	数据通信错误；接口数据错误
功能缺陷	功能无法实现；功能实现错误; 由此可能会影响程序设计需求或基本功能的使用
安全缺陷	权限无法实现；访问控制错误；加密错误；超时限制错误；web安全漏洞(xss，csrf)等
兼容性缺陷	在需求规定的配置下，出现的兼容性问题，兼容性可以是软件、接口或界面等
性能缺陷	未达到预期性能；性能测试出错
界面缺陷	操作界面错误；内容、格式错误；没有提示或提示不合理；长时间操作未给出提示；界面不规范等；此缺陷会令用户使用不方便，但不影响程序的正常执行和功能实现
建议	功能建议；操作建议；

创建缺陷

在缺陷面板中, 找到创建缺陷的选项

填写相关的表单信息

缺陷名, 出现该bug的模块名称
执行人, 谁来修复这个bug, 或者这个bug是谁的
时间, bug开始修复和修复完成的时间, 由执行人填写
假如是迭代里的功能bug, 则需要选择对应的迭代
备注, 按照规范详细填写重现步骤, 测试结果, 期望结果
缺陷分类, 这个不用管它, 当然你也可以在左侧进行创建, 按照功能模块名进行创建
严重程度, 这个根据测试人员进行主观判断
缺陷类型, 测试人员必须根据事实进行选择, 不可留空, 也不可乱选
标签, 不管它, 用处不大

测试计划

测试计划中, 保存的是测试人员自己创建的测试用例分组

测试人员可以创建多个测试计划, 一个测试计划下, 可以包含多个测试用例

例如:

测试计划: 个人中心

测试用例:

上传头像
修改个人信息
xss测试
…….

创建测试计划

在测试计划面板中, 找到创建测试计划的按钮
在弹出的模态框中输入测试计划的名称

在右边找到 “创建用例”, 填写以下信息

测试用例标题, 例如个人中心xss测试
执行人, 代表要执行本条测试用例的人
前置条件, 如: 用户已登陆, 浏览器最新版, 字符长度必须符合要求等, 这些由开发人员告知
操作步骤, 软件测试人员执行本测试用例的具体步骤

流水线

在讲流水线之前, 我们先来看一个项目开发情景

创建项目
代码开发 ↔ git push
集成测试 && bug修复
服务器部署 && 项目上线

这一环节换成流程图表示就是这样子:

有没有发现, 我们在开发过程中, 代码开发与测试 是软件开发周期中, 持续时间最久的部分.

其中会经过 无数遍的代码修改, 测试, 提交, 构建, 部署 ,干开发的同学应该深有体会, 这一步虽然不难, 但是很繁琐, 浪费生命

在大公司的项目开发过程中, 前端后端开发者的代码都是先经过构建并部署到内部的测试服务器, 让测试人员通过内网域名去访问项目并执行测试.
测试人员不可能来你旁边问你: 嘿兄弟, 你运行一下项目, 然后把链接发我测试一下, 这是不可能的!!!
通常公司会有自己的内网服务器, 自建私有代码库, 一个测试团队动则几十上百人, 必须得是用内网域名访问项目进行测试的

所以, 在以前还没有CI/CD工具出现时, 将代码构建, 部署到内网服务器的这一系列步骤, 都是开发人员自己 手动完成 的.

但是现在不一样了, 为了让开发者能够专注代码开发, 其它不必要的环节全都改成了自动化了

也就是让我们的服务器 自动拉取代码库的代码, 自动下载依赖, 自动构建, 自动运行, 如下图

右侧的绿色框框, 代表了部署项目的每一个环节和步骤(当然, 我这里没有写全), 每一个步骤都必须按顺序执行, 环环相扣, 上一个执行完了, 才能开始执行下一个步骤, 肉眼看下来就类似于一条线, 而这条线, 就称之为 “流水线”

CI/CD平台

我们常见的CI/CD平台有以下几个

Jenkins
Gitlab CI
TeamCity
Travis CI
Circle CI
AppVeyor
Azure
Pipelines
BambooCI
CodeShip
GoCD

其实还有更多, 以上介绍的主要是开源的, 闭源的就更多了, 总之呢, 开源的CI/CD工具之中, 最出名的估计就是 Jenkins 和 Gitlab 了

当然, 这不在我们的讨论范围内, 毕竟我们的主题是云效

云效不算是CI/CD平台, 因为CI/CD只是云效体系下的一个功能而已, 别忘了云效还有代码托管, 项目跟踪, 概览等一些列功能

因此, 云效应该称之为 Devops 一站式平台

创建流水线

明白了流水线和持续集成等概念, 我们就来实践一下, 创建一条流水线

我们以 React项目自动部署 为例

进入流水线

进入云效工作台, 点击左上角的图标, 打开侧边菜单栏

在菜单栏中找到流水线

创建流水线

点击新建流水线的按钮

选择 “其它 - 空模板”, 然后点击创建

代码源

点击流水线源, 在代码源配置中, 选择云效代码库, 也就是 Codeup, 至于其他源的话, 你们感兴趣可以自己去研究

代码库配置如下，最后点击 ”添加“

代码仓库, 代表这条流水线要应用到哪个代码库身上
默认分支, 手动触发或者定时触发流水线时, 流水线获取的代码分支
开启代码源触发, 代表代码库的代码发生何种变化时, 会触发流水线执行, 这里我们勾选 “代码提交”, 代表当我们 push 代码时, 流水线会自动运行
开启分支过滤, 一般我们的代码库会有很多个分支, 如果我们不开启分支过滤的话, 代表只要有push行为, 所有的分支都会被流水线运行, 但其实我们只想让指定的分支运行, 而不是全部分支都运行 , 这里我们写了 dev, 代表只有 dev 分支被push时，才运行流水线
工作目录，流水线运行时，会自动下载我们的代码到它自己的工作空间里，进行自动化构建操作，一般我们把工作目录名称改成跟项目名称一样就可以了

添加新任务

点击第二列的空任务

在弹出的面板中，进行任务配置

任务名称：随便写，最好是你的项目名+执行环节
构建集群：默认即可
下载流水线源：下载部分流水线源
流水线源：这其实就是刚刚我们配置的 工作目录

点击添加任务步骤，选择Node.js构建，配置如下

步骤名称：也是随便写，这个看你自己了，最好跟步骤名一样
版本选择方式：你自己选择
Node版本：也是看你自己的选择
构建命令，你这里写的命令会自动在项目的根目录下执行，如果你有多个命令，一行写一条，它们会被分别执行的

构建物上传

接下来，我们再添加一个步骤，选择 ”上传 - 构建物上传“

步骤名称：依然是随便写，但写的规范一点
上传方式：跟我选的一样
制品名称：云效会把你指定的打包路径，添加到一个压缩包里，制品名称其实就是这个压缩包的文件名
打包路径：把哪个路径下的文件放到压缩包内，React/Vue项目build后的目录是dist，我们这里写dist就可以了

配置新任务

React构建配置我们已经完成了，接下来，我们配置新的任务

找到 ”部署“ 选项，由于我们的项目最终要部署到我们自己的服务器上，因此我们选择 “主机部署”

填写以下信息，然后点击 “主机组”

任务名称：也是随便起
勾选 “部署时下载制品”，其实也就是下载上一个任务中，build出来的dist目录压缩包
制品：你选择就好了，它会自动出现给你选择
下载路径：把制品下载到你服务器上的哪个位置？
执行用户：下载到你服务器上之后，用哪个用户来执行？
主机组：你的服务器分组，如果没有的话，你就需要新建，由于我的服务器是腾讯云的，所以我选择 “自有主机”

在弹出的面板中，复制下面的命令，然后去登录你的服务器上，用root用户执行它，同时，这个面板也不要关掉，它会自动刷新的

当你在自己的服务器上执行以上命令后，你就会发现列表出现了你的服务器信息，勾选它，然后跟着提示选择进入下一步就可以了
接下来，配置我们的部署脚本

暂停方式：
- 第一批暂停：当有n个push触发到流水线时，第一个push的流水线会被暂停，寓意是让管理员先审核，是否允许构建
- 每批暂停：每n个push，都会触发到流水线，但是流水线暂停执行它，先让管理员审核，是否允许构建
- 不暂停：不管你，只要你push了，我就执行
分批数量：代表多少个push