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

前言

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

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

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

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

63c4d7b34870c3789ca40be260980016.png
不符合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插件,在保存关闭文件时就会自动格式化文件。

7b216cebda5b947074f6282e5407e5af.png
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仓库,。

396bef849f744b97338c7b596d78247e.png
github授权vercel

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

团队工作的额外操作

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

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

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

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

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值