为什么我要学习持续集成呢?
答: 因为想要将前端实现工程化.
什么是前端工程化呢?那我们就要来想一下,什么是工程化?很简单就是将人力重复的工作转换成机器运转,可以很大的节省成本。那我们前端如何实现工程化呢?
1、 模块化开发
简单来说，模块化就是将一个大文件拆分成相互依赖的小文件，再进行统一的拼装和加载。
2、 组件化开发
比如,给公司写了一个组件,其他人都在用,这种使用就是重复性的,每个人都不需要去自己写一个相同的组件了
3、“智能”加载静态资源（性能优化）
在打个比方,以前的性能优化依赖的是什么?是感觉,打开页面需要多久,完全凭感觉是降低了时间,还是增加了。那我们现在呢?使用别人或者自己公司做出来的性能优化的测试工具,将各种数据进行上报并展示给开发人员,使得开发人员知道哪部分需要优化,并提供优化方案。
4、规范化
规范化是工程化中很重要的一个部分了，项目初期规范制定的好坏会直接影响到后期的开发质量。那都规范那些呢?如下参考 :
- 目录结构的制定
- 编码规范
- 前后端接口规范
- 文档规范
- 组件管理
- Git分支管理
- Commit描述规范
- 定期CodeReview
- 视觉图标规范
…
5、自动化
自动化是工程化中很具有特点的一部分,完全的展示出了工程化的一些概念,不需要人力的去操作,完全是代码自行的运转
- 图标合并
- 持续集成
- 自动化构建
- 自动化部署
- 自动化测试
加入我们群。642830685，免费领取最新软件测试大厂面试资料和Python自动化、接口、框架搭建学习资料！
测试覆盖率
首先来开启一下测试覆盖率,如果你使用jest进行测试的,请按照如下步骤进行测试覆盖率的配置
好的,我们来开启配置,在jest.config.js中配置属性 collectCoverage: true, 这个属性代表着是否收集测试覆盖率,
jest-junit测试报表 reporters: [“default”,“jest-junit”],
但是你需要先安装jest-junit,运行 yarn add --dev jest-junit
collectCoverageFrom表示测试哪些代码
collectCoverageFrom: [“lib//*.{ts,tsx}", "!/node_modules/**”],
coverageDirectory表示生成的报告放在哪个目录里
coverageDirectory: ‘coverage’,
coverageReporters表示要生成哪些报告
coverageReporters: [‘text’, ‘lcov’]
补充一下,如果你不想要jest-junit报表可以不进行配置
在page.json文件中配置如下代码,他表示输出的目录
"ci": "cross-env NODE_ENV=test JEST_JUNIT_OUTPUT=./test-results/jest/results.xml jest --config=jest.config.js"
当我们配置好了之后,运行yarn ci,会生成coverage目录,用浏览器打开index.html文件你会发现,这里有详细的测试结果,根据测试的结果,对你的项目进行补充,比如性能,error,还有没测试到的位置
接下来我们来看看,下面这个代表什么意思
Statements代表着测试覆盖率
Branches代表着分支覆盖率
Functions代表着函数覆盖率
接下来我们要进行自动化测试,不要每次都自己跑一遍
首先我们使用的是circle ci这个自动化工具,用github登陆一下
之后点击如下,这是我要进行自动化测试的项目
进来之后我们选择的node环境
首先我们在我们的项目中,创建.circleci目录,在这个目录里创建config.yml文件,复制如下配置
#https://github.com/revolunet/create-react-app-circleci/blob/master/.circleci/config.yml
defaults: &defaults
docker:
- image: circleci/node:8 # 我们使用node第8版本来进行测试
version: 2 # 我是用的是第几版本的circle ci
jobs:
# 准备阶段
prepare:
# 迁出代码
<<: *defaults
steps:
- checkout
- restore_cache:
keys:
- v2-dependencies-{{ checksum "package.json" }} # 根据dependencies创建一个缓存
- run: yarn install # 安装所有依赖
- save_cache: # 保存一下缓存
paths:
- node_modules # 缓存的目录
key: v2-dependencies-{{ checksum "package.json" }}
- persist_to_workspace:
root: .
paths:
- node_modules
build:
<<: *defaults
steps:
- checkout
- attach_workspace:
at: .
- run: yarn build
- persist_to_workspace:
root: .
paths:
- dist
- package.json
- LICENSE
- README.md
test:
<<: *defaults
steps:
- checkout
- attach_workspace:
at: .
- run: yarn ci # 运行yarn ci
- store_test_results:
path: test-results # 将测试的结果报错到ci上
publish: # 测试通过进行自动化构建
<<: *defaults
steps:
- attach_workspace:
at: .
- run: npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN
- run: npm publish
# 这里配置了测试的顺序
workflows:
version: 2
build_accept_deploy:
jobs:
- prepare
- build: # build之前要先运行test
requires:
- test
- test: # test之前要先运行prepare
requires:
- prepare
- publish:
requires:
- build
filters:
tags:
only: /^v[0-9]+(\.[0-9]+)*/
branches:
ignore: /.*/
配置完成之后需要先提交你得代码,到你的分支,之后点击这里
然后就会自动跑起来了
当我们每次git push的时候都会自动运行
我又把" jest-junit "这个配置加回来了
擦,翻车了,第一次明明成功了,之后始终错误,提示我不兼容
改了这里才发现我本地安装的node是10版本的,我配置的是8版本的,这才导致不兼容,配置改成下载的本地node版本,切记切记!!!
我们在提交的时候不需要提交test-results目录下的文件,在配置一下!
补充:
发布自己的代码,给用户使用的方式
在 package.json 文件里新增一个配置
"files": [
"/dist/**/*"
],
然后运行 yarn publish 不建议使用npm,全是bug…,脑瓜疼
确认版本号,如果不需要更改,照着输入一遍,然后输入你得用户名,邮箱,密码,如果报错
切换你得源,改为npm源, npm config set registry https://registry.npmjs.org ,在次运行成功
哈哈哈哈哈,成功发布,自己使用自己发布的试试,运行 cd /tmp/
创建一个目录先 mkdir demo-1 , cd demo-1 , npm init -y , yarn add reactwheel888 , 依次执行
哈哈哈,打开我们的目录 start . ,在node_modules目录里面找到我们项目名字的目录
我的dist目录也上传上来了,nice!!!完成
但是我得配置应该是每次测试完成自动就可以发布的,他咋不发布呢???
是因为每次自动发布的时候都会告诉我没登陆…
解决办法是在npmjs官网上创建一个token,这个token放在circleci的环境变量中(这里需要注意: 你的项目里面点击settings才能进来)
之后运行如下代码 git commit . , add npm token , :wq , git push ,但是配置里的这段代码会导致你得publish不执行
自动增加版本号的配置 npm version patch 会自动帮你升级版本
如果你回滚了 npm version minor
如果你真的需要每次上传代码进行自动部署,这段代码删除掉,但是我不希望,为什么?我的版本可能不改变,我的项目可能未完成,我还部署就过分了…这里我就先不更新了，先建议大家不要配置这个自动的publish,手动的publish吧,我会继续研究如何能我想要什么时候publish就什么时候自动的publish的.
如果想要不迷路,请关注一下吧,谢谢大家支持!!!如果有问题请留言,我会回复的!!!了解更多，加入我们，有技术大牛解惑，同行一起交流
总结:
1、项目工程化好处
2、测试以及测试覆盖率配置
3、自动化测试配置
4、npm自动打包发布