盒子
盒子
文章目录
  1. 前言
  2. 本地代码进仓库要经历什么
  3. 推到远程仓库后要做什么
  4. 项目部署
  5. 团队工作的额外操作

将写完的代码提交上线中间发生了什么

前言

前端工程化,是面向公司的代码模块化、系统化、规范化的一个过程,在这个过程中,经过了这个过程,我们才能称得上是“正规军”。

前端工程化,有很多方面,如代码提交规范、模块化、CI/CD等,通过方方面面的约束,让代码变得可读性强、易维护等,随着项目越来越大,工程化的优势日益凸显出来。

本地代码进仓库要经历什么

Github官方给出了一些钩子函数git hooks,使Git能在特定的重要动作发生时触发自定义脚本,分为两类,客户端和服务端的,我们常用的有pre-commitcommit-message等。

前端工程化的第一步,合格的代码

什么样的代码是合格的,我们可以借助代码检测工具ESlint等,定制一套规范,例如:

1
2
3
4
5
6
7
8
9
module.export = {
rules: {
// ...
'react/jsx-no-target-blank': 'error',
'react/jsx-uses-react': 'error',
'react/jsx-uses-vars': 'error',
'no-unused-vars': 'error',
}
}

如代码所示,该规则约定,当有变量声明但未使用,属于no-unused-vars,返回结果error,命令行会报错。

规则已经定好了,接下来就是自动检测代码是否合格。

然后就是几个关键的工具库

husky是Git hooks工具,可以防止一些不好的commit和push。

lint-staged是一个在git暂存文件上运行linters的工具。

pre-commit钩子在键入提交信息前运行,用于检查即将提交的快照。

prettier代码格式化工具。

package.json加入:

1
2
3
4
5
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
}

这样就完成了代码检测,可以试着运行一下git commit命令:

不符合eslint

可以看到,前边类型为error,且后边给出了不符合eslit的no-unused-vars规则,本次commit提交失败。

在代码符合规范之后,我们再使用prettier对规定范围内的代码做格式化处理。先在package.json中添加命令,规定要格式化的代码文件:

1
2
3
4
5
{
"scripts": {
"prettier": "prettier --config .prettierrc --write {.,components,lib,pages}/*.js {components,lib,pages}/**/*.js",
}
}

之后就可以使用命令行格式化范围内的代码。

在vscode中也可以添加prettier插件,在保存关闭文件时就会自动格式化文件。

image-20210208222125459

完成上述配置后,在执行git commit命令后,但凡是有不符合代码,都会被禁止提交,只有将所有位置的代码修改后,才能提交,再push到仓库。

推到远程仓库后要做什么

代码被推到github后应该跑CI做自动化测试,例如lintteste2ecodeQLsecure等。

我们可以在项目中添加一个目录.github/workflows,在该目录中添加文件,构建工作流程。

我们应该先在github action里重新运行一遍自己的项目,我们应该写这些内容:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
name: CI

on: [push]

jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Use Node.js 12.x
uses: actions/setup-node@v1
with:
node-version: 12.x
- name: npm install, lint, build, and test
run: |
npm install
npm run lint
npm run build
npm start & npx wait-on http://localhost:3000 && npm run cy:run -- --config baseUrl=http://localhost:3000
env:
CI: true
CYPRESS_CI: true

这段代码将项目运行在ubuntu环境中,顺便做了个e2e测试。

然后再做codeQL:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
name: "CodeQL"

on:
push:
branches: [main, ]
pull_request:
# The branches below must be a subset of the branches above
branches: [main]
schedule:
- cron: '0 10 * * 3'

jobs:
analyse:
name: Analyse
runs-on: ubuntu-latest

steps:
- name: Checkout repository
uses: actions/checkout@v2
with:
# We must fetch at least the immediate parents so that if this is
# a pull request then we can checkout the head.
fetch-depth: 2
- run: git checkout HEAD^2
if: ${{ github.event_name == 'pull_request' }}

# Initializes the CodeQL tools for scanning.
- name: Initialize CodeQL
uses: github/codeql-action/init@v1

- name: Autobuild
uses: github/codeql-action/autobuild@v1

- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v1

项目部署

我的前端项目部署在vercel.com上,授权访问github仓库,。

github授权vercel

每次push代码到github时,github会发请求给vercel,携带本次push的信息,然后vercel将代码拉过去,重新运行构建部署代码。

团队工作的额外操作

对于团队工作来说,一般是自己新开一个分支,push代码到该分支。

在合并分支之前,除了应该做的测试、规范检查之外,也要做Code Review,检查代码的逻辑问题等。

在push到个人分支运行测试时,会为该分支生成一个preview的url,检查各项功能。

一切都没有问题之后,才会允许合并到主分支。

最终主分支的代码通常会手动部署。

欢迎关注公众号
扫码关注我的微信公众号-大前端合集
  • 微信公众号-大前端合集