01.⼯程化服务环境介绍

简介图

本地开发：编写 eslint 、stylint 和 prettier 规则⽂件，配合vscode的保存⾃动格式化，再严格的话加上git hook 来 检测

当我们对特定的分⽀做 push，或者在仓库执⾏分⽀合并更新后，就会触发我们的 CI / CD 服务：去⾃动构建我们 的代码（当然可以加上⼀些单元测试、代码质量检测等），构建成功后⾃动帮我们部署到对应的开发环境、测试环 境，预发布环境，部署线上⽣产环境的话⼀般是设置⼿动更新等，当然还需要快速回滚的功能，CI / CD 服务运⾏ 的状态最后都要做通知，通过：邮件、钉钉企业微信等，告诉团队或者相关开发⼈员构建的结果等

知识点⼤图

CI / CD 流⽔线

CI 代表持续集成（Continuous Integration），CD 代表持续交付（Continuous Delivery）和持续部署 （Continuous Deployment）。也可以将它们看作是类似于软件开发⽣命周期的过程

简单的说，就是在本地更改代码—>git push推送到代码托管—>⾃动安装依赖，打包测试部署等（开发环境⼀般 ⾃动，⽣产环境⼀般是需要⼿动点击按钮上线）

CI / CD 流⽔线⼯作图

⾃动化流程的必要性：避免很多问题，少解决很多冲突，假设你的前端团队有6个⼈，每个⼈电脑的系统、node版 本，npm版本都有可能不⼀样，就算是规定统⼀了，每个⼈拉取代码源仓库 build 出来的产物也有可能不⼀样，这 样会产⽣⼏个问题 ：

• 耗时：每个⼈都需要去构建
• 易冲突：当git做pull ,merge,push等的时候⼀不⼩⼼就会产⽣各种不必要的冲突要去解决，⾮常的耗时和不愉 悦
• 缓存失效：构建出来的静态⽂件的hash不好控制，容易在客户端失去缓存，即使在webpack中设置了 contenthash等等优化 例如：⼀个很⼤的commit.js，base.js,echat.js vendor.js啊等⽂件，本来是没有更新的，已经在客户端缓存的 了，却在这次更新后hash值莫名奇妙的变化了，再次访问⻚⾯后客户端的⽤户还需要重新去加载它们，浪费资 源啊⽼板

其实这些问题在⼤公司，⼈员完善的团队⼀般不会遇到，因为会有专⼈负责这⽅的搭建，但是你知道的嘛，初始的 ⼩团队，那种苦只有体验过的才知道 ，但是如果你会了，⼜有点话语权，那这问题就可以迎刃⽽解了 打造⾃动化构建部署 CI /CD 流⽔线服务的⼯具我们这⾥⽤的是Jenkins

Jenkins

ci / cd 现在有不少服务，github的GitHub Actions，gitlab 的Gitlab-CI,gitee的Gitee Go，还有travis、Netlify等 等，我们⽤Jenkins，引⽤官⽅的话就是：

Jenkins是开源CI&CD软件领导者， 提供超过1000个插件来⽀持构建、部署、⾃动化， 满⾜任何项⽬的 需要。

为了⽅便部署和迁移等，我们要在docker上安装Jenkins

Docker

Docker 是⼀个开源，轻量级的应⽤容器引擎,以前我们想在window折腾linux系统，在上⾯部署应⽤来测试什么 的，我们通常会安装⼀个虚拟机，在虚拟机上安装操作系统啊，应⽤什么的，搞垮了可以重新来什么的，不影响主 机的系统，不过虚拟机⽐较重，启动慢，现在我们⽤docker，相⽐于虚拟机装操作系统，Docker是使⽤容器承载 应⽤程序，轻量，⾼效，⽅便快捷的部署

Docker 由镜像(Image)、容器(Container)、仓库(Repository) 三部分组成。

Verdaccio

Verdaccio 是⼀个 Node.js创建的轻量的私有npm proxy registry ，⼩团队⽤这个够

Yapi

Yapi这是⼀个api管理平台，前后端分离的时候，api mock显得格外重要，没有api、mock，团队的朋友得在代 码中做⼀堆测试数据，判断条件什么的，后⾯等接⼝开发好再删掉测试的数据，在对接接⼝重新测试，这可⼀点都 不好玩。现在主要的mock系统有rap2、eolinker，yapi等等，我们这⾥⽤yapi，轻量简单功能好，社区活跃star ⾼，需要mongoDB来存数据

MongoDB

MongoDB使⽤C++语⾔编写的⾮关系型数据库。特点是⾼性能、易部署、易使⽤，存储数据⼗分⽅便。这⾥我们 安装是提供给yapi⽤

Git flow ⼯作流

简单的先说⼀下我们⼩团队这⾥的 git flow，这样好明⽩我们接下来的 CI / CD 要为我们做什么
代码运⾏的环境 ⼀般来说，⼩公司⼩团队都会有⾄少这⼏个环境：

• 本地开发环境： 开发⼈员⾃测的，可以是⾃⼰本地部署的静态服务器，当然也可类似是运⾏ npm server类似的环境，本地环境运⾏ 的代码可以是任何分⽀的
• dev开发环境： 这个环境是⽤开发分⽀dev产出的代码来部署的，唯⼀的公⽤的
• 测试&预发布环境： 这个环境是⽤开发分⽀release产出的代码来部署的，唯⼀的公⽤的
• 线上⽣产环境： 这个环境是⽤开发分⽀master产出的代码来部署的，唯⼀的公⽤的

git 分⽀模型

先看⼀下分⽀的⻆⾊功能

分⽀的策略

dev 是公共的开发分⽀，不会合并到其他分⽀去的,

所有的分⽀都是基于master分⽀检出

• master ：保护分⽀，对应的就是⽣产环境的分⽀
• release：保护分⽀，所有开发完成的分⽀会申请合并到release分⽀，提供给测试⼈员测试
• feature-*：功能分⽀，具体功能开发
• dev：开发分⽀&脏分⽀，对应的是⼤家共⽤的开发环境，上⾯的代码会部署到⼀个公共的开发环境，供开发⼈ 员做⾃测，应付⼀些⽇常、⾮⽇常的调试
• hotfix-*：bug紧急修复分⽀，可以直接合并到master，（假如release合并了⼏个feature分⽀，正在测试的情况 下，发现需要紧急修复的buf，紧急修复测试完毕后，可以直接合并到master，如果合并到release，在由 release合并到master，那些正在测试的功能或者还不准备上线的功能就会跟着直接上线了）

  ⼯作流程

• 1.接到需求⽂档，做评审后分配个每个⼈或⼩组的功能开发，相关⼈员从master 检出功能分⽀
• 1. 开发的时候除了会在本地测试，有需要还会合并到dev分⽀，在公共的开发环境去⾃⼰做测试
• 1. 因为在开发功能的期间，可能有hotfix完成合并到master，合并代码的时候习惯merge⼀下master，防⽌冲突 等
• 1. ⾃测完成之后，申请合并到release，合并成功后部署到测试环境后通知测试⼈员做测试
• 1. 测试通过后，release申请合并到master，准备上线
• 1. 如果测试不通过，在功能分⽀修改后重新merge
• 1. 上线成功稳定后删除对应的功能分⽀，dev 合并最新的master分⽀