概念
持续集成（Continuous integration，简称 CI）
持续集成指的是，频繁地（一天多次）将代码集成到主干。
好处：
(1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
(2）防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
目的：
- 更快地发现软件潜在问题，加快团队合作软件开发速度
- 让产品可以快速迭代，同时还能保持高质量
流程：
- 代码提交
- 测试第一轮（hook触发单元测试）
- 构建
指将源码转换为可以运行的实际代码，（经过第一轮测试，代码合并进主干）
构建工具： Jenkins
Jenkins是一款开源的持续集成工具，它的特点：易于安装、易于配置、可扩展（自己开发插件），并且它拥有数以百计的成熟插件，这种插件式的特点提供可做任何事情的可能。
- 测试（第二轮）
全面测试，单元测试和集成测试都会跑，有条件的话，也要做端对端测试
需要强调的是，新版本的每一个更新点都必须测试到。如果测试的覆盖率不高，进入后面的部署阶段后，很可能会出现严重的问题。
- 部署
经过第二轮测试，得到一个可部署版本，将这个版本的所有文件打包（ tar filename.tar * ）存档，发到生产服务器
- 回滚
一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。
传统做法：
- 开发完成后才布测试环境
- ⼿⼯部署
- 手动修改配置
- 手动回归测试
效率低，质量无法保证，安全风险高，流程复杂，自动化程度低，成本高
集成测试做法：
- 统⼀的代码版本管理库（Git）
- 自动化编译，打包和发布
- 自动化测试
- 全程对团队透明
工具：
Git - 版本控制
Docker - 测试环境搭建
Jenkins - 持续集成服务器
持续交付（Continuous delivery，简称 CD）
指频繁地将软件的新版本交付给质量团队或者用户，以供评审，如果评审通过，代码就进入生产阶段。
持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。
持续部署（continuous deployment）
是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。
持续部署的前提是能自动化完成测试、构建、部署等步骤。
Gitlab CI/CD 和 Docker+Jenkins 如何选型?
线上拨测 弥补CI/CD
对网站、域名、后台接口等进行周期性监控，查看拨测任务的可用率和延时，设置阈值告警，异常实时通知，及时对业务质量作出反应，保证业务稳定正常运行
白盒测试
主要应用在单元测试阶段，主要是对代码级的测试，针对程序内部逻辑，测试手段有：语句覆盖、判定覆盖、条件覆盖、路径覆盖、条件组合覆盖。
黑盒测试
主要用来测试系统的功能是否满足需求。着眼于程序外部结构，不考虑内部逻辑，针对软件界面和软件功能。
测试类型
单元测试（unit testing）
单元测试在测试分层中处于金字塔最底层的位置，单元测试做的比较到位的情况下，能过滤掉大部分的问题，并且提早发现 bug，也可以降低 bug 成本。
要点
- 白盒测试，更注重数据的流动
- 是集成测试的基础
- 针对基础框架和通用组件（函数或模块）
技术方案：
Jest
支持 Matchers 方式断言；
支持 Snapshot Testing，可测试组件类代码渲染的 html 是否正确；
支持多种 mock，包括 mock 方法实现、mock 定时器、mock 依赖的 module 等；
支持 istanbule，可以方便的获取覆盖率。
Install Jest using yarn:
yarn add --dev jest
Or npm:
npm install --save-dev jest
业界比较易用的 js 覆盖率工具，它利用模块加载的钩子计算语句、行、方法和分支覆盖率，以便在执行测试用例时透明的增加覆盖率。它支持所有类型的 js 覆盖率，包括单元测试、服务端功能测试以及浏览器测试。
$ npm install -g istanbul
集成测试
针对整体产品的某个功能的测试，又称功能测试
E2E测试（end to end）
端到端测试则对应的为黑盒测试，即只测试输入输出，不考虑过程状态的测试方式，更注重结果的展示，从用户界面直达数据库的全链路测试
UI自动化测试
问题1：维护成本高
问题2：前端重用户交互，单纯的接口测试、单元测试不能真实反映用户的操作路径
要点
提供统一的包来处理公用组件、特殊页面的通用逻辑，封装通用方法等
技术方案：
puppeteer，它是由 Chrome 维护的 Node 库，基于 DevTools 协议来驱动 chrome 或者 chromium 浏览器运行，支持 headless 和 non-headless 两种方式。官网提供了非常丰富的文档，简单易学。
UI 自动化框架有很多种，包括 selenium、phantom；对比后发现 puppeteer 比较轻量，只需要增加一个 npm 包即可使用；
它是基于事件驱动的方式，比 selenium 的等待轮询更稳当、性能更佳；
另外，它是 chrome 原生支持，能提供所有 chrome 支持的 api，同时我们的业务场景只需要覆盖 chrome，所以它是最好的选择。
mocha + mochawesome
mocha 是比较主流的测试框架，支持 beforeEach、before、afterEach、after 等钩子函数，assert 断言，测试套 件，用例编排等。
mochawesome 是 mocha 测试框架的第三方插件，支持生成漂亮的 html/css 报告。
js 测试框架同样有很多可以选择，mocha、ava、Jtest 等等，选择 mocha 是因为它更灵活，很多配置可以结合第三方库，比如 report 就是结合了 mochawesome 来生成好看的 html 报告；断言可以用 powser-assert 替代。
线上核心接口|页面拨测
性能检测：
- 性能评分标准
- 图体积优化（oss）
- 性能优化指引
*lint检测
兼容性检测
包检测，基础库变更报警
- 对比一次 master 代码的提交或 merge 请求，判断 package.json 中是否有特定基础库版本变更
- 增加change log，判断测试范围
API 检测
Assets检测、域名合法性检测
线上监控
sentry 是一款开源的错误追踪工具，它可以帮助开发者实时监控和修复崩溃。
使用
sentry 的全局信息上报，并进行筛选
- 错误类型: TypeError 或者 ReferenceError
- 影响因素：通过多维度区分错误等级
- 错误出现在 js 文件中
- 增加核心业务异常流程的主动上报
最终将筛选后的错误信息通过邮件的形式发送给告警接收人，在固定的时间集中修复。
其他
Gerrit code review
Gerrit 代码审核
Sonar 检测
代码静态扫描 Code Quality & Security for JavaScript
It uses the most advanced techniques (pattern matching, dataflow analysis) to find Code Smells, Bugs, and Security Vulnerabilities.
功能：使用模型匹配和数据流分析等先进技术，查找 代码异味（代码中的任何可能导致深层次问题的症状）、bug和安全漏洞。
SonarLint for VS Code
SonarSource's JavaScript analysis supports:
- ECMAScript 5 / ECMAScript 2015 (ECMAScript 6) / ECMAScript 2016 / ECMAScript 2017
- React JSX
- Vue.js
- Flow
常见的代码异味：
代码重复: 相同或者相似的代码存在于一个以上的地方。
长方法: 一个非常长的方法、函数或者过程。
巨类: 一个非常庞大的类。
太多的参数: 函数或者过程的冗长的参数列表使得代码可读性和质量非常差。
特性依恋: 一个类过度的使用另一个类的方法。
亲密关系: 一个类依赖另一个类的实现细节。
拒绝继承: 子类以一种‘拒绝’的态度，覆盖基类中的方法，换句话说，子类不想继承父类中的方法，参考里氏替换原则。
冗余类 / 寄生虫: 一个功能太少的类。
人为的复杂: 在简单设计已经满足需求的时候，强迫使用极度复杂的设计模式。
超长标识符: 尤其，在软件工程中，应该毫无保留的使用命名规则来消除歧义。
超短标识符: 除非很明显，一个变量名应该反映它的功用。
过度使用字面值: 为提高可读性和避免编码错误，应该使用命名常量。此外，字面值可以且应该在可能的情况下，独立存放于资源文件或者脚本中，在软件部署到不同区域时，可以很方便的本地化。
使用Jenkins+Sonarqueb进行自动化测试和代码质量检测
SonarQube静态代码质量检测【前端】
pipeline
pipeline 快速入门
参考链接：
持续集成是什么
为什么要持续集成与持续部署
