GitHub Actions 自動化流程設計與安全部署最佳實踐

說到 GitHub Actions，唉，其實這玩意兒最近幾年常常在開發圈被提到。有人會說它像個無形的助理吧，總是在你那些 repository 裡默默等著，好像沒什麼存在感，但關鍵時刻又能跳出來幫大忙。嗯，不過它也不是隨便亂動，通常就是 push 到主線、拉了個 PR 或者你設置了定時任務，它才會開始跑流程。這種安靜地潛伏然後突然就工作起來的感覺，有點詭異又讓人安心。

對了，很多人都把這些自動觸發叫做「event」，其實這詞……我第一次看到還愣了一下。不過想想也是，每次有點風吹草動，就能啟動一連串預先寫好的流程（workflow）。這 workflow 彈性超級大，比如有人甚至直接拿它跑 Terraform 腳本，在專案裡部屬資源什麼的——好像已經離自動化測試很遠了欸，不小心扯遠，再拉回來。重點是，它應用場景真的夠多變，也難怪被大家愛用。

講到怎麼設定 pipeline 安全或細節問題，老實說還真不簡單啦。有時候看官方文件根本霧煞煞（我每次都得讀兩遍），不是按個按鈕就解決那種。有些細節還得自己慢慢摸索，一不小心就踩坑。我記得有朋友曾經為了解某個 bug，在那邊卡了幾天才終於找到原因，那種挫折感太真實。

所以，如果你真的想混熟 GitHub Actions，到底要怎麼辦？嗯，大概就是多上手、多試案例吧。有的人喜歡一次衝到底，但更多工程師可能是分段學習、逐步嘗試之後才比較抓得到訣竅。我常懷疑到底有誰能完全掌握所有細節，不過據說沒幾個人能做到這點啦…所以別太焦慮，大概也只能慢慢補洞和修正吧。

說到 GitHub Actions，嗯，其實你只要點開一個倉庫，那個叫做 `.github/workflows` 的資料夾基本上就直接躺在裡面。這地方專門塞流程設定檔，看起來就是一堆 yaml 格式的文件，好像有點亂但又沒真的亂到哪去——大致都照著某種規矩排著。有時你會看到像「Run Tests」那種名字，說實話感覺和記事本貼的標籤沒什麼兩樣。唉，我常常滑過去都忍不住想，要是能自動分類多好，結果還不是得自己找。

到底它們怎麼運作？有人問過我這問題，好啦我也不敢說我全懂，但大概意思就是：你推送程式碼進主分支、或偶爾開個 pull request，也都可能觸發那些流程。然後，有些人總記得三四種觸發事件，大致離不開每天寫 code 會遇上的情境吧。我有時候腦袋打結還會忘了是哪幾種……反正往下看，流程其實都拆成幾段在跑；最顯眼的大概就叫 jobs 吧，看起來像大家分工，有啥任務就丟給不同人（雖然根本是機器）。

舉例好了，有時候測試工作很愛挑 ubuntu-latest 這台虛擬機器，不過說穿了所謂 latest 也不知道是不是永遠最新，只能信它表面而已啦。每一步驟被叫做 step，有些人龜毛一點喜歡用「Check out code」（感覺好像先把東西領出來存），另外一些則乾脆直接安裝 Node.js 新版本——通常也就是十位數左右的版本號，很難記清楚，每次查半天。再接著嘛，就 npm install 一下，把套件拉進來，最後執行自己那串神祕的測試指令。不知道為什麼，每次打這些命令，都覺得跟前一天重複度九成九，可偏偏每回又卡在不同地方。

老實講整體架構其實簡單啊，就是先報名字（name），再宣告哪些 on 事件才啟動，最後 jobs 裡面塞滿細節。選平台完畢之後，每一步要加減隨便你，有些人愛 run 下 shell 指令，也有人懶得管直接 call 現成 action，比方 actions/checkout 或 setup-node。我常常做到一半才想到：「欸等等，上次是不是漏了一步？」然後又倒回去補充。有時哪段步驟乾脆被忽略掉，也沒有誰規定一定不能省事，全看需求拉鋸罷了。所以搞到最後，你以為穩妥無漏洞，其實只是剛剛好湊合罷了吧。

欸，講到設計自動化流程這種事，其實多數人一開始根本沒把資訊安全當一回事，真的，不誇張。我以前也差不多啦——反正系統能跑就好，是不是？然後總是等哪天出包了、資料外洩還怎樣才會驚覺：「呃，原來安全性還蠻重要的喔。」嗯，好啦，拉回來。至於 GitHub Actions 要怎麼照顧這些安全上的疑慮，我印象裡至少有幾個切入方式，大概可以試著摸索看看。

唉，有時候大家寫程式怕麻煩，就直接把密碼或那些看起來很機密的參數塞在檔案裡頭——說真的，那真的是在冒險。GitHub 其實給了一套相對低調、專用儲存祕辛的小東西叫 Secrets。我那次亂逛專案設定，發現底下有個「安全性」區域，然後還藏了「Secrets 與變數」，點進去會看到可以跟行動（Actions）搭配的一坨設定。不過我常常搞混哪邊是哪邊，有點懶得翻細節……但只要新增一筆秘密，把敏感內容丟進去就結束。

引用 secret 時候啊，其實格式長得挺普通：
steps:
- name: Deploy to production
run: ./deploy.sh
env:
API_TOKEN: ${{ secrets.API_TOKEN }}
有人嫌這流程囉嗦啦，但老實說，比明碼硬寫腳本裡放心太多。雖然偶爾還是會覺得有點懶，不過算了。

而且除了 secret 還有權限控制這件事。老實講，每次聽朋友聊，都覺得複雜又迷糊——因為 GitHub 的 workflow 好像預設都給一些 token，可以讀也能改倉庫內容，但具體到底開多少權限，其實很少人願意仔細看官方文件啦。有時候想，如果什麼都全開，一旦發生預期之外的狀況……唉，到時候崩掉就自求多福吧。我中間想到什麼晚餐該吃啥（咦），結果忘記我要強調收斂授權的重要，趕快拉回主題。

每次遇到細節問題就去查官方文獻，可是認真說，看了半天都霧裡看花，大概懂個五分之三而已。不過總歸一句，各家環境不同，要補強工作流程的安全性，就是多用心、多比較方法，再挑自己適合的做法吧。畢竟世界不太可能萬無一失，只能盡量保守地加點備案，也只能如此，大概吧。

通常啦，這個權杖預設給的操作空間都比你實際上會用到的還要寬裕不少，有點像—嗯，給太多反而讓人心慌。其實你完全可以手動把權限鎖得更死一點，比方說寫成
permissions:
contents: read
pull-requests: write
issues: write
這種格式就行。唉，雖然有時候覺得手動調太麻煩，可是真的多一層心安。

講到第三方 Actions 的版本控制，不少人偷懶直接抓個大號，比如 actions/checkout@v1，看起來沒什麼問題對吧？但萬一 v1 被重新指向，你哪知道現在跑的是哪個版本——而且這種小細節常常被忽略掉。有人選 minor version（像 v1.2.3），其實已經精確很多，只是嘛…又不是完全沒風險。如果真的想求穩，大概只能咬牙指定到單一 commit SHA 才有保障。不過有人抱怨這樣很難維護，到底該怎麼折衷？我自己也搞不定，每次都糾結半天。

朋友聊起來時總會嘆氣，他們專案裡頭偶爾還是會不小心把密鑰、token 那堆東西推進去，怎麼檢查都漏掉幾次。市面上倒是有些自動化工具啦，例如 gitleaks 就挺常見。只要弄個 YAML 設定，在 push 或 PR 時跑個掃描流程，就能稍早抓包。但欸，要注意 config 路徑到底設對沒？路徑錯了結果怪怪的，也挺無奈。

大家都越來越在意安全性嘛，所以不少人乾脆在 CI/CD pipeline 裡頭加上各式安全掃描，種類說來也複雜。一種就是靜態程式碼分析，例如 CodeQL 之類，可以針對 code 找出漏洞或潛在危機。他們通常設定主分支 push、PR 或每週固定執行一次；流程並不神祕，就是 checkout 程式碼→初始化 CodeQL→開始分析。有時候突然想到語言支援，其實 JavaScript、Python 都能跑啦，其它語言差不多也是那套邏輯。

另外一派則特別在乎依賴套件帶來的風險，畢竟外部元件踩雷機率誰敢保證零。有些人直接用 npm audit 這類工具，快速過濾目前裝了哪些有已知弱點的套件。整體流程蠻直白的——先 checkout 程式碼，再裝 Node.js 跟相依套件，最後直接審核。有疑慮再討論怎修補就好。有時候光是查結果就夠壓力山大。

最近資安圈子裡陸續冒出一些 AI 輔助型工具，比如 DeepCode AI，好像能補傳統掃描抓不到的小毛病。不過想用之前還得申請 API 金鑰，那種授權資訊缺了啥都不能做。另外 Snyk 算熱門吧，它同樣靠 AI 偵測與協助修復資安議題，有開發團隊說效果還算 OK……可最終成果如何，好像還是要搭配自己需求跟其他手法一起評估才安心。我有時候也搞不清楚，到底該信哪邊比較好。

至於基礎設施自動化（Infrastructure as Code）這塊，Terraform 可以說近年討論度超高，一直被拿來舉例。在 GitHub Actions 上跑 Terraform 流程嘛，其實也沒什麼稀奇，但慢慢變成某些團隊日常維運不可或缺的一環。唉，我現在想到還會猶豫到底該用多少自動化才不會出事，不過…話說回來，人總得試試看才知道啊。

有些人在整那種自動化流程時，總是要把 Terraform 跟 GitHub Actions 搭在一塊。這件事聽起來不怎麼高深，其實步驟就那幾樣啦。欸，突然想到，有人說第一步得先拉下程式碼，不拉好像哪裡怪怪的——呃，好吧，反正大部分人都已經習慣這套動作，只是大家各自的小招略有不同。

然後就會開始用 HashiCorp 出的 setup 工具，把 Terraform 環境給安置妥當。嗯，他們家的版本有時候會換一下，但其實看需求而定，也不是老是要更新。有點跑神，剛剛還在想是不是去年用過舊版，但回來講主題吧，反正就是設定環境。

初始化應該算很早期就必須搞定的事情了，基本上沒辦法偷懶省掉。尤其如果你在雲端混，比如 AWS，那個密鑰什麼的總不能亂丟，常見做法多半直接扔進密碼庫裡頭——嗯，是比較保險啦。不過偶爾也有人怕麻煩亂放，這種情況...唉，也只能提醒小心。

格式檢查這回事，好像越來越多團隊會要求開發者遵守，看起來只是讓大家寫出來的程式碼不要落差太誇張。坦白講，也不是每家公司都抓很緊，可是某些地方規矩特別嚴格，你要是不照著弄還真不行。有時候覺得規範太多挺煩，但又能怎樣呢？繼續講回流程好了。

所謂計畫（plan）步驟，就像是在預演操作結果，其實蠻有用，可以提前發現一些莫名其妙的錯誤設定。大概很多工程師也是為了求個安心感才愛跑這一輪吧。有時 apply 只在主分支真的被推送新內容才啟動，我記得文件上也是這麼寫——主分支加推送雙重條件才動作，所以 pull request 階段通常只是走形式啦，不會真的下手。

總之整體而言啦，這種工作流本質上就是希望基礎操作可以自動、穩定地運作。但現實嘛，每次都完全照劇本走根本不可能，好像永遠會蹦出臨時狀況。一兩個環節失敗也沒啥稀奇，有時候自己遇到跟其他團隊比對，又會冒出細節差異——說穿了，就是個參考值罷了。

5 . 大致上會先列個改動方向，像腦袋裡浮現某種草圖。這通常是我的習慣，算吧。不過也有那種時候，明明想好藍圖卻突然發愣在原地——唉，腦袋空白一片。6 . 然後才開始真的動手做，把變更都壓到主線分支上——其實大多數情境下都是這麼搞的，我偶爾也會懷疑該不該再設條臨時分支，但最後還是直接硬上了。

## 關於 Terraform 安全掃描這事

有些人喜歡在自己的 Terraform 流程裡頭，加一道安全檢查的步驟。其實我以前覺得沒什麼必要，但現在回頭看，好像也挺重要的。舉個例子，如果你需要讓代碼自動檢查，那下面這類 YAML 文件就很常見：

name: 'Terraform with Security Scanning'
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
terraform:
name: 'Terraform'
runs-on: ubuntu-latest

steps:
- name: Checkout
uses: actions/checkout@v4

- name: Setup Terraform
uses: hashicorp/setup-terraform@v3
with:
terraform_version: 1.5.0

- name: Terraform Init
run: terraform init

- name: Terraform Format
run: terraform fmt -check

- name: Terraform Security Scan
uses: aquasecurity/tfsec-action@master
with:
soft_fail: true

- name: Terraform Plan
run: terraform plan
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

- name: Terraform Apply
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
run: terraform apply -auto-approve
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

其中有一步會跑 tfsec，其實就是拿來幫你的基礎設施代碼掃一輪風險。有的人覺得這只是在多此一舉，可是說真的，有時候出包還真的是因為少了那層防護網。啊對，我差點忘記講重點——很多團隊現在都考慮加這一招。

## 有點生活味道的應用場合

不知道你們是不是碰過：要把 Node.js 應用部署到幾個不同環境裡。有時 production、staging、dev 全部分流，就容易搞混。我自己試過兩次，一次手忙腳亂差點傳錯地方。然後，下面那段腳本其實不少人參考：

name:'Deploy Application'
on:
push:
branches:
- main
- staging
- dev
jobs:
deploy:
runs-on : ubuntu-latest

steps :
– uses : actions/checkout@v4

– name : Set up Node.js
uses : actions/setup-node@v4
with :
node-version :'20'

– name : Install dependencies
run : npm install

– name : Run tests
run : npm test

– name : Determine environment
id : environment
run :
if [ $GITHUB_REF == "refs/heads/main" ]; then echo "env=production" >> $GITHUB_OUTPUT; elif [ $GITHUB_REF == "refs/heads/staging" ]; then echo "env=staging" >> $GITHUB_OUTPUT; else echo "env=development" >> $GITHUB_OUTPUT; fi

– name : Deploy to environment
run : ./deploy.sh ${{ steps.environment.outputs.env }}
env :
API_TOKEN:${{ secrets.API_TOKEN }}
推到哪條分支就自動丟去對應環境。有些開發者直呼方便，不怕手殘失誤。但話說回來，有一次我還是按錯 commit message 差點沒看懂流程……嗯，總之自動化多少能救命。

## 定時資料庫備份的小插曲

大家偶爾還會討論怎樣每天晚上定期備份資料庫。我之前看到有人乾脆直接寫成排程腳本，例如像下面這樣：

name:'Scheduled Database Backup'
on :
schedule :
– cron :'0 0 * * *' # 每天半夜排程一次
jobs :
backup :
runs-on ：ubuntu-latest

steps：
– uses：actions/checkout@v4

– name ：Setup Terraform
uses ：hashicorp/setup-terraform@v3
with ：terraform_version：1.5.0

– name ：Terraform Init
run ：terraform init-backend-config="path=./terraform/database-backup"
working-directory：./terraform
env：
AWS_ACCESS_KEY_ID:${{secrets.AWS_ACCESS_KEY_ID}}
AWS_SECRET_ACCESS_KEY:${{secrets.AWS_SECRET_ACCESS_KEY}}

–name：Run Database Backup
run：terraform apply-auto-approve-var="backup_name=backup-$(date +%Y-%m-%d)"
working-directory：./terraform
env：
AWS_ACCESS_KEY_ID:${{secrets.AWS_ACCESS_KEY_ID}}
AWS_SECRET_ACCESS_KEY:${{secrets.AWS_SECRET_ACCESS_KEY}}
反正時間到了它就自己跑，也不用半夜起來顧心跳。當然啦，有人覺得交給自動化很安心，但我有朋友曾經遇過備份檔案壞掉隔天才發現……欸，好像又扯遠了，拉回來，不管怎麼樣，多一道保險總是好的，大概吧。

有時候，遇到那種狀況根本說不明白的 GitHub Actions 流程，其實大家手頭上也只有幾種方法可以試啦。有人就會建議，「欸，要不要把日誌弄得更詳細一點看看？」可是這招說真的，好像也不是每個人都習慣。嗯，對了，那個叫 `ACTIONS_RUNNER_DEBUG` 的祕密參數，感覺蠻多人推崇的——你只要設成 true，它據說就會開始拼命吐出訊息。但話又說回來，我自己老是記不起全部細節，就是靠環境變數塞進去，大致如此吧。

講到如果本來就在用 GitHub Actions Toolkit 工具的人，他們大概反而直接在流程裡面下指令輸出 debug 訊息，也就是 echo 幾行，有時甚至警告、錯誤都直接寫。雖然乍看普通，但這些東西排查起問題來，偶爾真有點作用。有一次我差點把 workflow 弄壞，好吧，不重要——總之順手插兩句 debug 文字其實還算方便。

再深入一層喔，就是那些碰到死角問題才會想到的方法。例如工程師乾脆搞一組臨時 debug 用的流程，把 workflow_dispatch 加進去讓你能自己按鈕觸發，加碼裝個 tmate 外掛——噢對，它其實就是 SSH 連線開放機會啦。不過坦白講，用起來不見得一路順風，所以除非真的是卡很久，誰想一直連呢？有時候我都懶得等那條連結生出來…。

最後嘛，多半大家腦中第一個念頭還是直接跑回去翻流程紀錄囉。GitHub 平台自帶那些 log，其實內容已經比以前豐富很多，可以順著找卡住的位置。但偏偏這類紀錄往往字海洶湧，你想立刻抓到關鍵細節還挺難的，需要慢慢瞪著螢幕、左翻右找蛛絲馬跡。有些 bug 就只能靠這樣耗時間摸索……唉，沒辦法，有些情形怎麼看都是沒頭緒，大概，只能硬著頭皮繼續查吧。

有時候我會打開自己的 GitHub 倉庫嘛，右上角那個 Actions 常常晃來晃去。欸，那天我其實本來只是想看看 commit 記錄，結果手滑點了進去。啊，裡面出現一串工作流程紀錄——每一條都像在說「快來查查我是做什麼的！」。這些執行過程，有時候亂長一段，看了頭有點暈，但偏偏又不能不看嘛。日誌攤開來，其實就算字數繁多、有點煩，還是能幫忙釐清到底發生什麼事。嗯，我也不知道自己為什麼會一直往下滑，可能只是好奇吧。

說到 GitHub Actions，其實網路上流傳滿多經驗談。有些工程師講得挺直白：你要是把流程寫得太複雜，以後自己都記不得維護啦。我看到有人直接分享——真的啦——他們習慣讓自動化腳本只處理單一目標。然後，他們會把大流程拆成兩三個獨立小段落，不要全部擠在同一條長長的流水線裡。不知道為什麼我突然想到咖啡機卡豆子的畫面，好啦，拉回主題。所以切割成不同部分來跑，好像更清楚易懂。有的人強調，如果任務很龐大，記得各自分工處理比較保險；畢竟簡單直接比較不容易搞砸吧。不過，每家公司、團隊各有奇招，大夥兒選擇方案也未必全然一樣。有時想想，其實每個系統背後都有那種莫名堅持在裡頭齁。

有時候，你會不會覺得一直在重複貼上一模一樣的步驟？唉，光想就煩。嗯，我也常這樣，不過其實還是有點方法能減輕這種機械式的折磨。像不少團隊乾脆把那些常用、很瑣碎又常改動的設定流程，額外做成一個合成動作檔案，然後扔進專案資料夾很裡面的一層，例如 .github/actions/common-setup/action.yml 這類亂長的路徑。說起來內容其實沒多複雜，大致都先設好 Node.js 環境——二十版現在好像特別受青睞，不知是不是什麼默契吧——接著就是 npm install，那行老掉牙指令再怎麼厭煩也只能硬著頭皮跑下去。有幾次我甚至發現因為某些細節或突發小更新，同樣東西就硬生生寫兩次，也怪奇怪，但多數狀況最後結果差不了太多。

講回主題，如果改天其他 CI 流程要套用同個片段，其實只需要用路徑 ./.github/actions/common-setup 就搞定了欸，不必再手工搬運那些七零八落的小步驟。這邊順帶岔一下，有人喜歡和 actions/checkout@v4 搭配使用，一口氣串測試腳本什麼的，整體大概三四步就收尾。不過，每間公司的寫法風格可能都差很多，看久了反而覺得挺荒謬──明明事情差不多，各自都要繞點彎。

對了，有時你想讓執行快一點，也不是沒人提過加快取嘛，把 node modules 塞進 runner 的 ~/.npm 目錄，好處據說是能省下每次重灌依賴包的時間。我自己試了一陣子（唉還真的是忍不住手癢），感覺如果 package-lock.json 有異動，那 cache key 隨之換掉，就比較不怕抓到舊東西。restore-keys 那條嘛，通常一起補個 runner 作業系統名上去備用，看似囉嗦但對大型專案來說還挺管用的──只是初學者可能光看到文件頭就暈了。

又想到，有些團隊根本玩到瘋，一鼓作氣把不同平台、Node.js 幾組主流版本全丟進所謂矩陣配置。例如 Ubuntu、Windows 和 Mac 都排進來，node 版本也是分三四種群組輪番跑。欸那 workflow 一看就眼花，但每一步自動根據 matrix 值切環境倒是滿省事，下意識少操好多心。一跑完 checkout，就按 matrix 指派好的 node 版本去安裝然後照表測試一次——彷彿人不用插手，但其實背地裡出錯機率還是不低啊。

總之啦，我覺得 Github Actions 本身彈性夠大吧？適合處理自動部署、基礎設施管理、安全掃描……諸如此類零碎繁瑣的活兒。但話說回來，要用得順利，也不能忽略 workflow 結構清晰與聚焦的重要性。我聽過一些工程師邊做邊觀察，他們認為分工仔細、命名明確反而更容易在出問題時火速定位原因。有空可以自己慢慢摸索哪些方法最習慣啦，畢竟每家情境不同，都怪各有特色；世上應該也找不到絕對安全萬全那種標準解答吧。

聽說，有一些工程師老是得在腦子裡轉著安全性的那些事，像是把機密東西藏起來、權限什麼的千萬別亂開太大——欸，有時候會想，到底是誰發明了這麼多層鎖。嗯，突然想到，就像你家鑰匙，應該不會隨便丟在門口吧？說來也奇怪，有些人還愛裝一堆安全檢查的小程式，感覺好像裝越多就越安心，其實只是比較容易早點抓到問題啦。不過每次能不能百分百擋住漏洞，也沒人敢拍胸脯保證，只能提高遇見危險之前的察覺機率，大概如此。

然後啊，不知道從哪年開始，用 GitHub Actions 搭配 Terraform，好像已經變成某些團隊每日例行公事了。有種「偷懶」但其實很正當的味道。自動化雖好，但總有那種莫名其妙的 bug 跳出來——debug 時候真的讓人火大。唉，我自己也常常卡半天，但慢慢摸下去，大致上終究還是找得到解法，只是每回都忍不住懷疑：真的沒有更簡單的方法嗎？

不過講到底，把這類手法混一起用，其實對專案流程有效率提升、也兼顧到一點安全性。有些資深前輩會說，你只要持續做下去，整體開發自然順順地推進……但我偶爾心裡會嘀咕，難道真有完全零煩惱的一天？大抵離那個理想狀態永遠差臨門一腳，就是這種微妙的不甘心讓人繼續琢磨吧。