DevOps 环境准备

一、团队沟通协作

1.1 方式

采用 notion 和线下组会结合的方式进行沟通协作。

1.2 notion 事项

1.2.1 TODO List

会记录任务，委派人，任务状态，截止时间，任务要求，大致如下所示：

1.2.2 成熟文档

每当完成一个阶段，都会有一个文档用于记录这一阶段的成果，到目前位置已经有 团队介绍，选题，Featurea， Demo 设计文档 四篇成熟文档。

每一篇成熟文档都发挥着类似于法规的作用。

1.2.3 scratch

草稿是成熟文档的前置阶段，用于在组会上记录或者是线上讨论不成熟的创意。

1.2.4 资源

资源呈现多种形式，有的是团队开发的图像资源，也有很多指导价值的帖子。

1.3 组会事项

1.3.1 总结上周工作

与会人员依次发言，介绍自己本周的工作。并在 TODO List 中修改状态。

1.3.2 商讨本周事宜

PM 会提前将本周的需要商讨的事宜记录在 notion 中，组员可以提前查看并准备。在组会中 PM 会组织大家商讨问题。

1.3.3 确定下周事项

根据商讨事宜，确定每个人下周的工作，并登记在 TODO List 中。

1.3.4 整理会议内容

PM 在会议结束后，会整理会议内容并更新到 notion 中。

---

二、代码管理

由于大家常用的 VCS 平台是 github，这次我们也选择使用 github 进行代码的管理。其优势主要如下：

1. 文档丰富，社区资源丰富，便于学习上手
2. 提供免费 github action 机时，对于没有较多 CI/CD 需求的项目不需要单独准备服务器

对于仓库的分支规范，我们要求遵守代码管理准备作业中的规范类型，将所有分支进行分类，按类别创建分支，管理。

1. 对于 main dev release 分支进行保护，不允许直接push (在 demo 项目中暂无此限制)
2. 其余分支必须经 PR 合并进保护分支
3. 在处理 PR 时，要求使用 rebase 而不是 merge

对于提交规范，我们要求团队统一使用 node.js 的 commitizen 包进行提交信息管理，不允许直接使用 git commit。

最终提交的 commit 格式类似这样：fix(.github): trigger CI-checkstyle in both push and manual

---

三、CI/CD

我们使用 github 进行代码的管理，使用 github 的 action 配置 CI/CD。

.github/workflows/npm-checkstyle.yml 文件如下：

name: eslint_checkstyle

on: [push, workflow_dispatch]

jobs:
  checkstyle:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 15
          cache: 'npm'
      - run: npm i eslint
      - run: node_modules/eslint/bin/eslint.js .

由于我们使用了 npm 进行包管理，如果每次 runner都要执行一下 npm i 的命令，会比较耗时耗流量。因此采用了 cache 的配置，保证包安装一次，重复使用。

由于项目仍处早期实验阶段，目前仅配置了一个语法检查的 action，暂未加入构建、发布、测试相关的 action。项目本身不需要服务端，也暂时没有相关部署的需求。

要求团队每一个成员创立一个名为 test-ci/[name] 的并 push，完成每人触发一次 CI 的任务。