代码完成到上线经历了什么
前言
前端工程化，是面向公司的代码模块化、系统化、规范化的一个过程，在这个过程中，经过了这个过程，我们才能称得上是“正规军”。
前端工程化，有很多方面，如代码提交规范、模块化、CI/CD等，通过方方面面的约束，让代码变得可读性强、易维护等，随着项目越来越大，工程化的优势日益凸显出来。
本地代码进仓库要经历什么
Github官方给出了一些钩子函数git hooks，使Git能在特定的重要动作发生时触发自定义脚本，分为两类，客户端和服务端的，我们常用的有pre-commit、commit-message等。
前端工程化的第一步，「合格的代码」。
什么样的代码是合格的，我们可以借助代码检测工具「ESlint」等，定制一套规范，例如：
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加入：
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
}
这样就完成了代码检测，可以试着运行一下git commit命令：
不符合eslint
可以看到，前边类型为error，且后边给出了不符合eslit的no-unused-vars规则，本次commit提交失败。
在代码符合规范之后，我们再使用prettier对规定范围内的代码做格式化处理。先在package.json中添加命令，规定要格式化的代码文件：
{
"scripts": {
"prettier": "prettier --config .prettierrc --write {.,components,lib,pages}/*.js {components,lib,pages}/**/*.js",
}
}
之后就可以使用命令行格式化范围内的代码。
在vscode中也可以添加prettier插件，在保存关闭文件时就会自动格式化文件。
image-20210208222125459
完成上述配置后，在执行git commit命令后，但凡是有不符合代码，都会被禁止提交，只有将所有位置的代码修改后，才能提交，再push到仓库。
推到远程仓库后要做什么
代码被推到github后应该跑CI做自动化测试，例如「lint」、「test」、「e2e」、「codeQL」、「secure」等。
我们可以在项目中添加一个目录.github/workflows，在该目录中添加文件，构建工作流程。
我们应该先在github action里重新运行一遍自己的项目，我们应该写这些内容：
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：
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，检查各项功能。
一切都没有问题之后，才会允许合并到主分支。
最终主分支的代码通常会手动部署。