前言 #

作为一个点了运维技能点的前端，解放双手是我一直追求的终极目标。

DevOps ，是 Development 开发与 Operations 运维的简写，用于促进技术开发、运营策划和质量保障三个部门间的沟通、协作和整合。

通过自动化，可以使得我们的 构建、测试、打包、发布、部署 变得更快捷、频繁和可靠。

为了按时交付产品和服务，开发和运维的工作必须是密不可分的。

整个工作流都是趋向于半自动化，甚至是全自动化。

DevOps 与 CI/CD，也是紧密相关的，那么 CI/CD 又是什么呢？

Continuous Integration，又称 持续集成，简称 CI，指多名开发者在开发不同代码时可频繁地将代码合且互相不影响工作。

Continuous Delivery，又称 持续交付，简称 CD，指在 持续部署 的基础上将产品交付到线上环境以实现交付高质量的产品。

通过 CI/CD ，我们可以实现工程流水线，将 构建、测试、打包、发布和部署 的过程，部分自动化，或者全自动化，节约时间，提高效率。

本笔记站基于 GitHub 提供的 Actions，实现了自动部署的工作流。

📓Ned的笔记站点

哪些工程需要自动化 #

个人认为，文档类站点是一定需要自动化的；再其次是个人服务器，如果对于自己开发的项目有部署情况的话，是需要来配置自动化来提高开发效率的；还有 npm 包（或者多包）的仓库，也是需要自动化的。

• 文档站点：在更新文档后，是一定要部署更新的
• npm 包（多包）仓库，在迭代更新后，最终会发布到 npm 仓库，发布的这个过程是可以使用自动化的
• 个人服务器：是可以使用自动化来部署更新自己的项目的

Github Actions #

本仓库就是基于 Github Actions 进行持续集成的，可以自动打包并部署，我们只需要更新文档项目的工程文件即可。

如何去写这一工作流呢？ GitHub 帮我们总结了许多已经写好了的：GitHub Marketplace

我们根据自己的需要去使用就可以。

一个完整的 Actions 由以下几部分组成：

• workflow：工作流程，是一个完整且独立的服务
• job：任务，一个或多个 job 可以组成一个 workflow
• step：步骤，一个或多个 step 可以组成一个 job
• action：动作，一个或多个 action 可以组成一个 step

GitHub Actions 的配置文件是 workflow 文件，存放在 .github/workflows 目录中，并以 <name>.yml来命名。

workflow 目录下的文件可以是多个，但必须为 .yml 文件。代码提交到仓库后，会自动挨个文件执行，直到处理完所有的服务为止。

以下列举一些配置文件的常见字段：

name 表示工作名称，若不设置默认为 workflow 文件的文件名称。若手动完成一个工作流程，会根据顺序执行 checkout 检出、build 构建和 deploy 部署，因此将工作名称合并简称为 CBD。

name: CBD # 动作名称

on 表示触发事件，上述提到的 Webhooks 可定义一个或多个 Webhooks ，通常是 push 与pull_request 。Webhooks 要指定操作的分支，通常是 master 或 main。

on: # 触发条件：在 push 到 main 分支后
  push:
    branches:
      - main

jobs 表示任务列表，使用对象表示，对象属性表示任务名称，会在 Actions 的执行时显示。

• name：任务名称
• runs-on：虚拟机环境，可选 ubuntu-latest/windows-latest/macos-latest
• needs：执行任务的依赖顺序
• steps：执行步骤，每个任务可将需执行的内容划分为不同步骤

steps 步骤下的主要参数如下：

• name ：步骤名称
• uses ：官方与第三方 Actions
• with ： Actions 的入参
• run ：执行命令
• env ：环境变量

jobs: # 任务
  cbd: # 任务 ID
    name: CBD # 任务名称
    runs-on: ubuntu-latest # 虚拟机环境
    steps: # 执行步骤
      # 拉取代码
      - name: Checkout
        uses: actions/checkout@v3
      # 打包文件
      - name: Build
        run: yarn && yarn run deploy
      - ...