帶著走的CI/CD：GitHub Actions! (Take the CI/CD with you: GitHub Actions!)

Yenlin Chen

Published in

Yenlin Chen

9 min readNov 17, 2019

GitHub Actions是GitHub在美國11/13號全面開放的CI/CD workflow系統。

何謂CI/CD?

CI/CD是Continuous Integration /Continuous Delivery的縮寫，倡導開發者應建立一套流程能夠在程式碼push到版本控制系統後，即時驗證並隨時有穩定可發表/部署的codebase。

CI: Continuous Integration

隨著軟體的複雜度日漸提高，傳統上利用專門測試團隊在發表前，為期數個月的測試方式已經不再可行。即時驗證主要的目標，就是在每次codebase被改動時，利用自動化測試把所有的功能都驗證一次。

雖然即時驗證概念上很簡單。但實際執行上並不容易。例如：測試必須在每次codebase改動後自動執行，跑測試也需要共享的運算資源。當測試的深度及廣度提高時，可能還需要其他相應的服務或系統，例如資料庫，或者在不同的作業系統上執行。當系統的規模變大，甚至可能需要做大規模的壓力測試。

CD: Continuous Delivery

當某個版本的codebase通過CI的”摧殘”後，其穩定度跟正確性應有顯著的提升，開發團隊也會能更有自信地把這個成果交付到使用者手中。CD就是自動化這個發表/部署的流程。常見的問題有：

如何做到沒有downtime的部署
發表的軟體在production出錯時，如何恢復之前正常運行的版本 (i.e. rollback)
如何在新舊版本間執行A/B測試
除了application跟主要的business logic之外，如何利用CD準確且穩定的部屬其他相應的資源，如資料庫等等。

“帶著走的CI/CD”：GitHub Actions的特色

Fork完跟著走

為什麼說是GitHub Actions是”帶著走的CI/CD”呢？因為GitHub上跟其他開發者合作的主要方式即fork跟提交pull requests。Fork基本上就是把原本的repository複製一份以便自己做改動。也因為使用GitHub Action的方式就是透過repository中 .github/workflows 所定義的workflows。而這些workflows在這個repository被forked的時候，會跟一起被複製。所以fork一結束，新的repository就馬上擁有了現有的CI/CD workflow設定。

大部分的GitHub Actions使用簡易

如果你選用的GitHub Actions是self-contained的（即不需要設定第三方服務），那通常使用起來很簡便。如這個呼叫Rust compiler的Action:

只需要短短三行，就能夠完成compilation：

      - uses: actions-rs/cargo@v1
        with:
          command: build
          args: --release --all-features

即使是設定比較複雜的Actions，例如：我最近撰寫的 cert-2-aws-creds GitHub Action，使用者在設定好相關AWS資源後，workflow中也只需要提供數個參數就可以使用：

jobs:
  demo:
    runs-on: ubuntu-latest
    steps:
      - id: tmpCreds
        uses: ThinkThenRant/cert-2-aws-creds@v0.1.1
        with:
            certificate: ${{ secrets.CERTIFICATE }}
            private_key: ${{ secrets.PRIVATE_KEY }}
            iot_endpoint: ${{ secrets.IOT_ENDPOINT }}
            aws_iot_role_alias: 'ThinkThenRant@cert-2-aws-creds'

Workflow中的GitHub Actions可以互相傳遞資訊

當一個GitHub Action在workflow中運行時，它可以接受其他已執行的Actions的輸出當作輸入，其本身也可以輸出數值，以便其他Actions來使用。如此的功能大大地增加了GitHub Actions的靈活度，甚至超過原本傳統CI/CD著重在artifacts promotion跟deployment的範疇。

例如：在以下的例子中，第二步驟就使用了第一個GitHub Action的輸出。

jobs:
  demo:
    runs-on: ubuntu-latest
    steps:
      - id: tmpCreds
        uses: ThinkThenRant/cert-2-aws-creds@v0.1.1
        with:
            certificate: ${{ secrets.CERTIFICATE }}
            private_key: ${{ secrets.PRIVATE_KEY }}
            iot_endpoint: ${{ secrets.IOT_ENDPOINT }}
            aws_iot_role_alias: 'ThinkThenRant@cert-2-aws-creds'
      - name: Check whether we can call STS successfully
        run: |
          AWS_ACCESS_KEY_ID=${{ steps.tmpCreds.outputs.aws_access_key_id }} \
          AWS_SECRET_ACCESS_KEY=${{ steps.tmpCreds.outputs.aws_secret_access_key }} \
          AWS_SESSION_TOKEN=${{ steps.tmpCreds.outputs.aws_session_token }} \
          AWS_DEFAULT_REGION=us-west-2 \
          aws sts get-caller-identity

超級簡易的Marketplace發布系統

當GitHub偵測到某個repository包含了尚未發表的GitHub Action。網頁UI會主動詢問是否要發表到Marketplace上讓使用者便於搜尋。

發表GitHub Actions跟平常cut一個release流程幾乎是一樣的，基本上也是使用git tag。但多了一些讓你的Action更便於使用者的建議：

對有一定經驗的軟體工程師，GitHub Action十分容易上手

我本身有數年程式工作經驗，但對Typescript完全是新手。上週末，心血來潮寫了一個GitHub Action：cert-2-aws-cerds後，不得不稱讚GitHub Actions團隊對於開發便利性的努力。總共我花在弄懂Actions如何運作，及debug的時間大概只有一兩小時，剩餘時間則花在實作我的Action內部真正的功能上。

GitHub Actions也提供了SDK，所以開發者也有共通的介面來快速地實作常用的功能，如讀取inputs及outputs等。

不滿意某個Action的運作方式嗎？Fork → 改善 → 自用送禮兩相宜 🤓

Actions本身都是儲存在GitHub上的repositories，所以當你想要改善某個現有的Action時，可以使用很熟悉的fork及遞交pull requests流程來跟原本的作者一起協力開發。即使你的pull request沒有被原作者接受，你還是可以很簡易地在workflow中使用自己的Action版本。

舉例來說，幾星期前我在使用actions-rs/toolchain Action的時候，發現它不支援某個我想要的功能。所以我就fork原本的Action，做了更新，並在我的workflows中改動了兩行，就可以很輕易地開始使用我自己的Action版本了🤩：