歡迎來到本系列的第九篇文章

在前幾篇文章中我們已經學會了CLI(Day4)、SDK(Day5)、以及CDK(Day6、Day7、Day8)如何用程式來部署 AWS資源，而今天，我們要探索CI/CD，從了解 DevOps(開發維運)開始，到CI/CD流程以及可用的相關工具。

維運工程：餐廳裡的自動化廚房

想像你正在經營一家餐廳：
廚師負責做菜（開發），服務生負責送餐（運維）。
如果廚師做完菜還要親自跑去送餐，餐點出餐慢又容易出錯；更糟的是，如果每次改菜單都沒有紀錄，顧客永遠不知道哪道菜更新了什麼，廚房也容易手忙腳亂。

這就是為什麼 DevOps 的精神很重要——它像廚房裡的自動化設備，讓菜能自動出餐，並確保每一次菜單更新都被清楚紀錄（版本控制），廚師只需專心做菜，顧客立刻就能享用最新的料理。

DevOps 無限循環圖 (Plan → Code → Build → Test → Release → Deploy → Operate → Monitor)

版本控制：修改的歷史紀錄

在軟體開發中，我們用 版本控制（Version Control） 來追蹤程式碼的每一次改動：

• 每個改動都有紀錄，可回溯。
• 團隊協作更安全，避免彼此覆蓋工作。
• 可以分支實驗，測試無風險再合併。

最常用的工具是 Git，而 GitHub、GitLab 或 Bitbucket 提供遠端倉庫，讓團隊成員可以協作開發。

CI/CD：自動化流水線

CI/CD 就像廚房的自動流水線：

• CI（Continuous Integration，持續整合）
  每次程式碼更新，就自動跑測試、檢查品質、生成可執行版本。

• CD（Continuous Delivery/Deployment，持續交付/部署）
  通過檢查後，程式碼自動部署到生產環境，確保最新功能快速且安全地上線。

版本控制 + CI/CD = 團隊協作 + 自動化，保證程式碼品質與部署速度。

AWS 的 CI/CD 工具：CodePipeline

AWS 提供 CodePipeline 來實現 CI/CD：

• 可以串接 CodeCommit（版本控制）、CodeBuild（建置）、CodeDeploy（部署）等服務。
• 自動化流程可視化，設定完成後，每次程式碼更新就自動跑完整流程。
• 支援事件觸發，例如 Git push 事件啟動 pipeline。

大概的流程會像這樣：
GitHub → CodePipeline → CodeBuild → CodeDeploy → AWS Services (S3, Lambda, ECS...)

優點：全 AWS 內建，整合順暢。
缺點：如果你想跨雲或在本地做實驗，可能較不靈活。

選擇 GitHub Actions 來實作

考量到學習與實作的方便性，我們將使用 GitHub Actions：

• 直接用 GitHub repo觸發 workflow。
• 可以部署到 AWS S3、Lambda 或其他服務。
• 跨平台、跨雲，而且社群資源豐富。
• YAML 配置簡單，支援條件邏輯、迴圈與矩陣策略。

在Github Action中 我們用 Workflow 來定義CI/CD pipeline(流水線)

WorkFlow是看起來像這樣的YAML文件：

yaml
name: Deploy Static Website

on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build Website
        run: npm install && npm run build
      - name: Deploy to S3
        uses: aws-actions/s3-sync@v1
        with:
          source-dir: ./dist
          bucket: ${{ secrets.S3_BUCKET }}

每次 push 到 main 分支，就會自動建置網站並同步到 S3，實現真正的 CI/CD 流程。

CI/CD 與雲服務串接的權限、憑證管理

在自動化流程中，CI/CD Pipeline 需要能夠「安全地」與雲端服務互動。這通常涉及到 IAM 角色或使用者帳號，以及對應的存取憑證（Access Key / Secret Key）。

我們會在本系列中使用 GitHub Actions 作為自動化工具，而在公開的Github repository，我們更必須遵守一下原則來確保我們帳號的安全性：

• 最小權限原則：讓 Pipeline 僅能操作它需要的資源，避免授予全域管理權限。
• 憑證安全管理：將憑證放在安全的環境中，例如 GitHub Secrets，而不是直接寫在程式碼中。

這一章節先讓大家知道 CI/CD 與雲服務之間需要憑證與權限管理，實作細節與最佳實務，我們會在下一篇文章中深入介紹。

結語

在今天的文章中，我們從 DevOps 的理念談到 CI/CD 的重要性，並實際看了如何透過 GitHub Actions 來把程式自動化部署到雲端的雛形。不過光有流程還不夠。如何安全地讓 Pipeline 與雲端服務交談才是真正的挑戰。而且我們絕對不能將金鑰硬寫 (Hard code) 在程式碼裡。

在下一篇文章中，我們將會正式深入 IAM 與憑證管理，一步步帶大家了解在AWS上權限與憑證管理的概念，讓我們的 CI/CD 流程不只自動化，還能在安全的框架下運作。