FTP 上傳已死！資深工程師帶你搞懂 WordPress CI/CD，用 GitHub Actions 打造不加班的自動部署流水線

嗨，我是浪花科技的 Eric。身為一個在程式碼海裡打滾多年的工程師，我還記得那些年，我們用 FTP 手動上傳檔案的日子。夜深人靜，客戶一個 call 來說網站掛了，你睡眼惺忪地打開 FTP client，一個一個比對檔案，然後心驚膽顫地按下「覆蓋」。上傳到一半，網路斷了、手滑傳錯資料夾了… 那種冷汗直流的感覺，簡直是工程師的共同夢魘。說真的，如果你現在還在用 FTP 部署，那不叫懷舊，那叫自虐啊！

今天，我就要帶你告別這種石器時代的工作流程，踏入現代化的開發領域：CI/CD 自動部署。特別是利用 GitHub Actions 這個強大又免費的工具，我們可以為 WordPress 專案打造一條全自動、零失誤的部署流水線。從此以後，你只需要優雅地 `git push`，剩下的髒活累活，就交給機器人去辦吧！

告別 FTP 時代的眼淚：為什麼你需要 CI/CD 自動部署？

你可能會想：「我的網站就幾頁，FTP 拖一拖也很快啊，有必要搞這麼複雜嗎？」問得好！這就像問「有計算機為什麼要學心算」一樣。短期看來，手動操作似乎直觀，但長期而言，自動化帶來的效益是壓倒性的。讓我這個老司機跟你囉嗦幾句，你就知道為什麼了。

• 降低人為失誤： 手動上傳最大的敵人就是「人」。你會忘記上傳某個檔案、傳錯版本、甚至刪錯東西。CI/CD 流程是標準化、程式化的，機器人不會累、不會恍神，每次都精準執行你設定好的劇本。
• 版本控制與追溯： 搭配 Git，每一次的部署都對應到一個明確的 commit。網站出問題？你可以立刻知道是哪一次的程式碼變更造成的，甚至可以快速回滾到上一個穩定版本。用 FTP？你可能連自己半小時前上了什麼檔案都忘了。
• 提升效率與速度： `git push` 之後，泡杯咖啡回來，網站就更新好了。你省下的時間，可以用來寫更有價值的程式碼，而不是盯著 FTP 的上傳進度條發呆。對整個團隊來說，這意味著更快的迭代速度和更高的產出。
• 更安全的部署： 你不需要把伺服器的密碼告訴團隊裡的每個人。透過 GitHub Actions 的 Secrets 管理，我們可以將敏感資訊（如 SSH 私鑰）加密儲存，只有 Action 的執行環境能存取，大大提升了安全性。

總之，導入 CI/CD 不只是換個工具，更是開發思維的升級。它強迫你用更嚴謹、更專業的方式來管理你的專案，這對個人成長和專案的健康度都是百利而無一害。

CI/CD 是什麼鬼？GitHub Actions 又扮演什麼角色？

好了，我知道你已經被我說服了。但 CI/CD 這些縮寫聽起來很嚇人，別怕，我用白話文幫你拆解一下。

CI (持續整合 – Continuous Integration) 的核心精神

CI 的重點在於「整合」。想像一下，團隊裡有多個工程師在開發不同的功能，大家寫完程式碼後，會頻繁地將自己的變更合併（merge）到主要的分支（例如 `main` 或 `develop`）。CI 的流程會在每次合併時自動觸發，執行一些檢查工作，例如跑自動化測試、檢查程式碼風格等，確保新的程式碼沒有「搞壞」原有的功能。它的核心理念就是「儘早發現問題，儘早解決」。

CD (持續部署 – Continuous Deployment) 的最後一哩路

當 CI 的檢查都通過後，就輪到 CD 上場了。CD 負責將這些「確認沒問題」的程式碼，自動地部署到伺服器上，讓使用者能夠用到最新的版本。從程式碼合併到實際上線，整個過程全自動化，這就是持續部署的終極目標。

GitHub Actions：你的免費專案管家

那 GitHub Actions 是什麼？它就是 GitHub 內建的 CI/CD 工具。你只需要在你的專案根目錄下，建立一個 `.github/workflows` 資料夾，然後在裡面寫一個 YAML 格式的設定檔（我們稱之為 workflow），告訴 GitHub Actions：「嘿！當我推送到 `main` 分支時，請幫我做 A、B、C 這三件事。」而 A、B、C 就可以是我們前面提到的測試、打包、部署等步驟。它就像一個任勞任怨的專案管家，24 小時待命，幫你處理所有自動化的雜事。

實戰開始！打造你的第一個 WordPress 自動部署流水線

理論說完了，來點硬核的。我們現在就一步步建立一個當你 `push` 程式碼到 `main` 分支時，會自動將檔案同步到你的主機的 workflow。

行前準備：你需要這些『裝備』

• 一個存放 WordPress 專案的 GitHub Repository（私有或公開都可以）。
• 你的網站主機的 SSH 存取權限。你需要能夠透過 SSH Key 免密碼登入。
• 對 Git 的基本操作有概念（`add`, `commit`, `push`）。

步驟一：設定 GitHub Secrets，把你的鑰匙藏好

我們絕對不能把伺服器的 IP、使用者名稱、SSH 私鑰這些敏感資訊直接寫在程式碼或 workflow 檔案裡，這等於是把家裡鑰匙掛在門口。GitHub 提供了「Secrets」功能讓我們安全地儲存這些資訊。

到你的 GitHub repo > Settings > Secrets and variables > Actions，點擊「New repository secret」來新增以下幾個秘密：

• SERVER_HOST: 你主機的 IP 位址或網域名稱。
• SERVER_USERNAME: 你用來登入主機的使用者名稱（例如 `ubuntu`）。
• SSH_PRIVATE_KEY: 用來登入主機的 SSH 私鑰。請將你本機 `.ssh/id_rsa` 檔案的內容完整複製貼上。
• DEPLOY_PATH: 你 WordPress 專案在主機上的絕對路徑，例如 /var/www/html/your-site。

步驟二：撰寫 Workflow 劇本 (.yml 檔)

在你的專案根目錄下，建立資料夾與檔案：.github/workflows/deploy.yml。然後把下面的程式碼貼進去。

# .github/workflows/deploy.yml

name: Deploy WordPress to Production

on:
  push:
    branches:
      - main  # 當 main 分支有 push 事件時觸發

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - name:  checkout code
      uses: actions/checkout@v3 # 步驟一：把 repo 的程式碼抓下來

    - name: Setup SSH Keys
      run: |
        mkdir -p ~/.ssh/
        echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
        chmod 600 ~/.ssh/id_rsa
        ssh-keyscan ${{ secrets.SERVER_HOST }} >> ~/.ssh/known_hosts

    - name: Install Dependencies with Composer
      run: composer install --no-dev --optimize-autoloader
      # 如果你的專案有用到 Composer，這一步會安裝 PHP 相依套件
      # --no-dev 表示不安裝開發用的套件

    - name: Deploy files via rsync
      run: |
        rsync -avz --delete \
          --exclude='.git/' \
          --exclude='.github/' \
          --exclude='wp-config.php' \
          --exclude='node_modules/' \
          ./ ${{ secrets.SERVER_USERNAME }}@${{ secrets.SERVER_HOST }}:${{ secrets.DEPLOY_PATH }}

工程師小囉嗦時間： 這段 YAML 碼到底在幹嘛？

• name: 這個 workflow 的名字，會顯示在 GitHub Actions 的頁面上。
• on: 定義觸發條件。這裡是當 main 分支有 push 事件時觸發。
• jobs: 定義要執行的工作。這裡我們只有一個叫做 deploy 的工作。
• runs-on: 指定這個工作要在什麼樣的虛擬環境執行，ubuntu-latest 是最常用的。
• steps: 這裡就是重頭戲，定義執行的每一個步驟。
• Checkout Code: 使用官方的 actions/checkout@v3 action，把你的專案程式碼下載到虛擬環境中。
• Setup SSH Keys: 這一步非常關鍵。它會讀取我們前面設定的 SSH_PRIVATE_KEY 這個 secret，並把它寫入虛擬環境的 ~/.ssh/id_rsa 檔案中，這樣後續的 rsync 才能免密碼登入你的主機。
• Install Dependencies: 如果你的外掛或主題是透過 Composer 管理的，這一步會自動安裝。記得加上 --no-dev，生產環境不需要測試工具。
• Deploy files via rsync: 這是部署的核心。rsync 是一個強大的檔案同步工具。
  • -avz: 常用參數，代表歸檔模式、詳細輸出、壓縮傳輸。
  • --delete: 這個超重要！它會刪除目標主機上有，但來源（你的 Git Repo）沒有的檔案。這樣可以確保主機上的檔案跟你的 Repo 永遠保持同步，不會留下舊的垃圾檔案。
  • --exclude: 排除不想上傳的檔案或資料夾。像 .git, .github 這些版本控制的設定檔，以及最重要的 wp-config.php，絕對不能上傳！

把這個檔案 commit 並 push 到你的 `main` 分支後，就可以到 GitHub repo 的「Actions」分頁，親眼見證你的第一個自動化部署流程跑起來啦！

進階思考：不只是複製貼上，打造『健壯』的部署流程

上面的流程已經能動了，但一個專業的工程師不會只滿足於「能動」。我們還要思考如何讓它更健壯、更安全。

`wp-config.php` 的愛恨情仇：如何優雅管理設定檔？

我們已經在 rsync 中排除了 `wp-config.php`，這是正確的第一步。因為這個檔案包含了資料庫密碼等敏感資訊，絕對不能進版控。那伺服器上的 `wp-config.php` 怎麼來？最佳實踐是：在伺服器上手動建立好一份 `wp-config.php`，它會永遠待在那裡，不受我們部署流程的影響。

部署後的儀式感：清除快取與資料庫更新

檔案上傳完就沒事了嗎？當然不是！很多時候我們需要做一些後續處理，例如：

• 清除 WordPress 的物件快取 (Object Cache)。
• 清除頁面快取 (Page Cache) 外掛的快取。
• 如果外掛有更新，可能需要執行資料庫更新。

這些操作的最佳工具就是 WP-CLI。我們可以在 rsync 後面再加一個 step，透過 SSH 遠端執行 WP-CLI 指令：

    - name: Clear Cache and Update DB
      run: |
        ssh ${{ secrets.SERVER_USERNAME }}@${{ secrets.SERVER_HOST }} "cd ${{ secrets.DEPLOY_PATH }} && wp cache flush && wp core update-db"

這樣一來，每次部署後，網站的快取都會被清空，確保使用者能看到最新的內容。

結論：自動化不是終點，而是新旅程的起點

從手動 FTP 到自動化 CI/CD，這不僅僅是技術上的轉變，更是工作心態的革新。它讓你從重複的、易錯的勞動中解放出來，專注於創造性的工作。今天我們介紹的只是一個基礎的部署流程，但它已經為你打開了 DevOps 的大門。你可以基於這個流程，繼續加上自動化測試、多環境部署（開發、測試、正式）、零停機部署等更進階的玩法。

別再猶豫了，今天就動手把你的專案也加上自動部署吧！告別半夜上傳檔案的恐懼，擁抱 `git push` 帶來的從容與優雅。相信我，一旦你體驗過自動化的甜美，就再也回不去了。

當然，打造一套真正企業級的 CI/CD 流水線，可能還會遇到資料庫遷移、環境變數管理等更複雜的挑戰。如果你在實作中遇到瓶頸，或是希望為你的團隊導入更完善的 DevOps 解決方案，浪花科技的團隊擁有豐富的實戰經驗。我們樂於協助你打造穩定、高效的開發與部署流程。

準備好讓你的開發流程升級了嗎？歡迎點擊這裡，填寫表單與我們聯繫，讓我們聊聊如何讓你的專案起飛！

延伸閱讀

• 告別FTP手動上傳惡夢！資深工程師手把手搞定 WordPress CI/CD，從 GitHub Actions 到資料庫遷移全攻略
• 不只是上傳！打造 WordPress『零停機』CI/CD 部署流水線：GitHub Actions 進階實戰
• 終結滑鼠手！資深工程師的 WP-CLI 神兵利器，讓你的 WordPress 管理效率原地起飛！