![](https://oscimg.oschina.net/oscnet/up-6de9625c61607a8f9db4dfd590f28cfebbc.png)

## 前言
說起自動化，無論是在公司還是我們個人的專案中，都會用到或者編寫一些工具來幫助我們去處理瑣碎重複的工作，以節約時間提升效率，尤其是我們做前端開發會涉及諸如構建、部署、單元測試等這些開發工作流中重複的事項，本篇文章就是介紹如何利用 GitHub 提供的 Actions 來完成我們前端的釋出自動化。

## Github Actions

### 什麼是 Actions

筆者個人理解為在某種條件下可被觸發的任務，利用一個個任務（Action）就可組建成我們的工作流，想要更詳細的介紹定義的同學可以移步 [官方Action定義](https://github.com/features/actions)，有助獲取更多的資訊，這裡就不搬運啦~

### 使用 Actions 的好處

前端自動化部署方案有多種，那麼 GitHub 推出的 Actions 有什麼魅力呢？在筆者看來，Action 在前端自動化釋出有下面 3 點亮點：

- **免費**，Action 可與 GitHub 中的 Repo 進行繫結（下圖所示，具體操作見下文），**開箱即用**：這就意味著我們不需要提供跑任務的機器，也不用管怎麼把任務流對接起來，只要簡單地熟悉規則，就能將專案 run 起來。而我們大部分覺得某個工具麻煩，是因為使用步驟繁瑣，若要實現功能 A，還需做 B/C/D 操作才行，這時候我們要麼放棄要麼轉向操作更簡單的工具，畢竟省時省事才是開發第一要務~
  
![](https://oscimg.oschina.net/oscnet/up-4da55832523627e1dd720dced0856e96467.png)

- **任務外掛化**，持續豐富的外掛開源市場：得益於 Github 定義了 Actions 規範，讓我們使用的 Actions 時都是按某種已知規則開發，這使得 Actions 更易於裝配複用，很多優秀的開發者在製作完成工作流後，將自己開發的 Actions 放到 GitHub 的 [Actions 集市](https://github.com/marketplace?type=actions)上去，這樣尚未完成自己常規工作流的開發，不需要額外開發這些已有重複邏輯直接使用現成的他人 Actions 即可。在筆者的實踐過程中，前端的構建部署工作流，就是用的各類現有的 Actions 組合實現的。
  - **和 GitHub 整合好**，可避免因為使用 Travis 等第三方工具引起額外的心智負擔，在 GitHub 上可直接檢視 CI/CD 的情況。

當然 Actions 還有許多其他好處，還待各位親自嘗試，至少使用過 Actions 的人都說好 ?

## Actions 在業務場景下的實踐

### 分析來源

因為 Nebula Graph 是一家做開源的分散式圖資料庫（[Nebula Graph](https://github.com/vesoft-inc/nebula)：[https://github.com/vesoft-inc/nebula](https://github.com/vesoft-inc/nebula)），專案均依託 GitHub 來管理，所以很自然地使用由 GitHub 免費提供的 Actions 來完成我們日常的**持續整合**等工作流，在前端業務上自然也不例外。

舉個例子，筆者開發了一個專門介紹圖資料庫  Nebula Graph 的官網，除了根據需求修改站點主題模板的開發人員，網站日常維護主要由運營同學來管理內建的部落格內容，而內容更新這個動作比較高頻，基本上每一天運營同學就會發布一篇技術性相關的部落格文章。為了讓內容更新這個動作完全不依賴於開發同學，站點實現實時部署更新，這就要求將內容釋出過程自動化，這也是我們前端日常使用 Github Actions 的主要場景之一。

### Actions 快速開始

要使用 Actions 是件容易的事情，前提只要你的 Repo 源同 GitHub 關聯，關聯之後根據以下操作就能實現你的前端部署自動化。

在 Repo 的根目錄中，建立一個名為 `.github/workflows/` 的資料夾，用來存放工作流的描述檔案，一個專案可以有多個工作流，這裡我們的工作流為前端的釋出。

然後，在建立好的 `.github/workflows/` 目錄中，以 `.yml` 為副檔名建立對應該工作流的描述檔案，命名可自定義，例如：publish.yml。

接下來，參考 GitHub 提供的工作流描述規則進行任務 Actions 配置，詳細可以看[官方文件](https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions)，當然覺得文件冗長可在網上隨便搜個簡單的例子直接複製試試，親測下很快就能摸清 Actions 配置套路。

下面是我們自己實現官網自動釋出工作流的配置摘要，加了少量註釋幫助大家理解：

```yaml
name:
on:
  push:
    branches:
      - master

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # 此處每一個name對應著一個Action，具體執行邏輯已被提供者進行封裝，暴露給使用者的只是需要使用者需要關心和配置的
    # 從master上獲取最新程式碼
    - name: Checkout Github Action
      uses: actions/checkout@master
    
    # 我們的站點使用Hugo框架進行構建，此處是下載相關環境
    - name: Setup Hugo
      uses: peaceiris/actions-hugo@v2
      with:
        hugo-version: '0.65.3'
    
    # 為了將資源部署到雲伺服器，此處下載一個ssh傳資料的工具
    - name: Setup sshpass
      run: sudo apt-get install sshpass

# 進行前端資源的構建
    - name: Build
      run: hugo --minify -d nebula-website

# 部署
    - name: Deploy
      uses: garygrossgarten/github-action-scp@release
      with:
          local: nebula-website
          remote: /home/vesoft/nebula-website
          # 涉及偏安全隱私的資訊，不要明文暴露在此檔案中，因為repo很可能是公開的，會被所有人看見
          # ${{ ... }} 會應用你在對應專案設定中，配置的對應serets的鍵值資訊，從而保護私密資訊不被看到
          host: ${{ secrets.HOST }}
          username: vesoft
          password: ${{ secrets.PASSWORD }}
          concurrency: 20
```

最後，便是提交相應改動，將分支推到遠端，只要符合工作流中我們預先定義好的觸發規則，對應的操作即可被觸發，比如，在筆者的實踐中定義了官網僅限 master 程式碼變動。

完成以上步驟，就能使你的工作流 run 起來，更詳細的介紹，可以看下 GitHub 提供的[幫助文件](https://help.github.com/en/actions/configuring-and-managing-workflows/configuring-a-workflow#creating-a-workflow-file)，此處就不再贅述。

### Actions 使用注意事項

#### 私密資訊保護

`.yml` 工作流配置檔案中，不要出現私密資訊，諸如：賬號、密碼、ip 等等，具體實操過程中你可將這類資訊通通放到 Repo 的 secrets 設定中新增，並以 `${{ secrets.xxx }}` 的變數訪問形式在配置檔案中使用。

![](https://oscimg.oschina.net/oscnet/up-f6bb65fac016d93b0d260a107ab3f22cba4.png)

#### 尋找合適 Action

在配置我們的工作流中，基於我們的目的是為了快速高效地完成工作，因此不大可能親自去開發每一個需要用到的 Action，一般操作是去現成的 [Actions 市場](https://github.com/marketplace?type=actions) 找尋已有的 Actions 直接使用。

對於一些處理敏感任務的 Actions，比如，上傳伺服器時若需將賬號、密碼傳給此 Actions，使用前最好檢視下這個 Actions 的具體實現，一來能預知其中是否存在的風險，二來也能滿足好奇心瞭解相應的 Actions 規範和實現機制，幫助自己下次開發 Actions 做技術積累。

#### 發揮想象力

根據實際的需要，我們的工作流搭配可能會有各類形形色色的需要，比如，筆者最開始使用 GitHub Actions 時，需要連線 VPN 才能訪問開發伺服器，剛開始沒太理解如何連線怕麻煩弄不了，後面慢慢找到對應的 VPN 命令工具做實驗並理解這個呼叫過程後，很快地實現了想要的效果。

這裡想說的就是，只要需求合理，肯定不只你一個人會遇到，而此時就會有兩種對應的解決辦法，一是運氣好地有現成的 Actions 等你使用，二是麻煩點自己用指令碼來描述，總之要有想象力~

#### 考慮免費 runner 的效能

runner 就是執行配置工作流的環境，是由 GitHub 免費提供給使用者使用，當然免費大機率意味著效能容量有限，對於一些大型專案的工作流來說，有時候免費的 runner 跑起來有些慢不滿足需求，此時可考慮自己提供 runner 來整合，比如像我們的 [Nebula ](https://github.com/vesoft-inc/nebula) 這樣大的專案就自己提供了 runner 環境，這裡不贅述，感興趣的可檢視 [Self-hosted runners 官方指引](https://github.blog/2019-11-05-self-hosted-runners-for-github-actions-is-now-in-beta/)。

## Actions 實踐小結

以上便是筆者在日常前端開發中使用 GitHub Action 的心得體會，Actions 還能完成更多不同型別的任務流程，比如持續整合，應該只有想不到沒有做不到的道理。

透過專案下的一個個工作流，能從各個方面避免重複瑣碎的工作，讓我們更專注於實現邏輯本身，我想這是工程師最希望達到的狀態。希望這裡的簡短介紹能給各位帶來幫助，另外歡迎大家關注和使用我們的 [Nebula開源圖資料庫](https://github.com/vesoft-inc/nebula)，謝謝?

> 作者有話說：Hi，我是 Jerry，是圖資料 Nebula Graph 前端工程師，在前端平臺工具開發及工程化方面有些小心得，希望寫的經驗分享能給大家帶來幫助，如有不當之處也希望能幫忙糾正，謝謝~

## 附錄

- Nebula Graph：一個開源的分散式圖資料庫
- GitHub：[https://github.com/vesoft-inc/nebula](https://0x7.me/itpub2github)
- 官方論壇：[https://discuss.nebula-graph.io](https://discuss.nebula-graph.io)
- 知乎：[zhihu.com/org/nebulagraph/posts](https://www.zhihu.com/org/nebulagraph/posts)
- 微博：[weibo.com/nebulagraph](https://weibo.com/nebulagraph)

![關注公眾號](https://nebula-blog.azureedge.net/nebula-blog/WeChatOffical.png)

使用 Github Action 進行前端自動化釋出

相關文章