那些多人混战的开发经验谈

今年年初，刚好被大学学长推坑 COSCUP 开发组，这次的官网是以去年为基础去做修改的，所以并没有花非常多时间做开发，更多的时间是与其它组长讨论需求(可能是我们的需求或是他们的)，不过，也因为这是属於多人的协作开发，我觉得自己也在这一次学到不少，所以就顺手纪录一下。

开源人年会 (COSCUP)
开源人年会起源於2006年，是由台湾开放原始码社群联合推动的年度研讨会，也是台湾自由软件运动重要的推动者之一。此活动通常一连两日，包括有讲座、摊位、社团同乐会等。除了邀请国际的重量级演讲者之外，台湾本土的自由软件推动者也经常在此发表演说，会议的发起人、工作人员与讲者都是志愿参与的志工。
-- 维基百科

BTW. COSCUP 今年与 RubyConf Taiwan 合作，并因应疫情全部转为线上举办，议程都是以直播/录影 + Youtube Q&A 的形式进行，时间在 7/31 - 8/1 ，欢迎有兴趣的朋友们一同参与。

开发流程

图片来源

一般来说，团队开发通常会选定一种 Flow 作为开发流程，因为这次的官网已经有了一定的基础，所以我们选择较为简易的 Github flow 作为开发流程。
比起 Git flow 有多种的 Branch ， Github Flow 真的非常简易，基本上在开发或是修改任何功能时都是使用同一套流程:

新增 Branch

以这次的经验来说，假设要修改的功能属於 session 的部分，我们会以 feat/session 命名:

git branch feat/session

新增完分支後，记得要切过去:

git checkout feat/session

提交 commit

切到开发分支後要干嘛呢?当然是开发并提交你的修改啦!

git commit -a -m"提交讯息"

等到功能都修正的差不多，我们就可以将它推回 Github 上:

git push origin feat/session

新增一个 Pull request

等到我们将 feat/session 推上去之後，便可以打开 Github repo 的网址，聪明的网站会侦测到 feat/session 新增了好多 commit ，并询问我们要不要新增拉取请求，画面像是这样:

Assign the reviewer

在新增拉取请求时，可以指派你的 Reviewer ，让他们帮你审查你的 Pull request ，如果有哪里不妥的地方就可以继续做修改。
以 Power Shell 为例，我们可以挑其中一个 PR 看看，其中就可以看到提交人跟审查人的互动。

Deploy

在这个步骤中，我们可以去跑一些测试脚本来检验 feat/session 这个分支上的专案有没有符合逻辑和通过测试。
不过，我们在这个部分的作法是等到 Branch 合并回 master 分支後才运行部属脚本，至於我们怎麽做等等会提到。

专案布署

我们今年从 Travis CI/CD 搬到了 Github actions ，所以从版本控制、 CI/CD 再到网站页面的托管都被 Github 一手包办了。
至於我们的 Deploy 脚本内容如下:

name: Deploy

on:
  push:
    branches:
      - main
      - master
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ${{ matrix.os }}

    env:
      SPREADSHEET_API_KEY: ${{ secrets.SPREADSHEET_API_KEY }}
      PRETALX_TOKEN: ${{secrets.PRETALX_TOKEN}}


    strategy:
      matrix:
        os: [ubuntu-latest]
        node: [14]

    steps:
      - name: Checkout ?
        uses: actions/checkout@master

      - name: Setup node env ?
        uses: actions/[email protected]
        with:
          node-version: ${{ matrix.node }}

      - name: Cache node_modules ?
        uses: actions/cache@v2
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-
      - name: Install dependencies ??‍?
        run: npm ci

      - name: Linting ?
        run: npm run lint

      - name: Build production ?
        run: npm run build

      - name: Deploy ?
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./dist

脚本说明

• 当 master/main 收到 push 或是触发 workflow_dispatch 时就会触发 Deploy 。
• 如果专案中有部分资料(如: API Key)，不方便对外公开，我们可以将资讯存放在 Github 专案中的 secret 中，存放以後再新增:

  env:
        SPREADSHEET_API_KEY: ${{ secrets.SPREADSHEET_API_KEY }}
        PRETALX_TOKEN: ${{secrets.PRETALX_TOKEN}}
  
  

  就能够顺利读取这些资料了!
  • 其他 Job 中的 step 多半使用官方或是他人提供的脚本，我们可以针对个人需求去做客制化。

Workflow dispatch

刚刚提到了当我们触发 workflow_dispatch 时， Deploy 脚本就会被 Github actions 执行，那我们该如何触发该事件呢?

参考上图，我们可以切换到专案中 Github actions 的分页，并找到你想要 Re-run 的流程按下 Run workflow 。
为了方便其他工人的操作，我们也特别修改了之前的 Travis CI Trigger ，让它支援 Github actions 。

专案连结: Simple Github Actions Trigger

操作的方式也很简单，只要先修改 config.json:

{
  "port": 5000,
  "sessionKeys": ["keys", "keyskeys"],
  "github_actions": {
    "token": "your github personal access token",
    "repository": {
      "owner": "COSCUP",
      "workflow_id": "",
      "branch": "",
      "name": "2021"
    }
  }
}

接着输入以下命令:

npm i # 安装相依套件
npm run start

即可顺利运行!

Reference

• Simple Github Actions Trigger
• Understanding the GitHub flow
• COSCUP