代码完成到上线经历了什么

前言

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

前端工程化，有很多方面，如代码提交规范、模块化、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，检查各项功能。

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

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