在 Google Cloud 上用 Claude 打造應用（第 2/2 段）

🧑‍🏫 這段示範怎麼用 Claude Code 把一個收集使用者回饋的 app 放上 Google Cloud。Claude Code 是讓 Claude 直接寫程式、執行指令的工具，Google Cloud 則是 Google 的雲端服務平台。上線前會先做安全檢查，最後分析使用數據、做成報表。這段值得看，是因為示範者一再強調：你不懂 Google Cloud 也能把整件事做完。

• 12:19 目標架構：原始資料存在 BigQuery（分析型資料倉儲），建一條 data pipeline，再用 Looker 這類 dashboard 工具把資料視覺化
  ↳ BigQuery 是 Google Cloud 上專門存放大量資料、拿來分析的倉庫。data pipeline 是整理資料的流程。Looker 會把資料畫成 dashboard，也就是圖表儀表板。整套就是存資料、整理、看圖三步。
• 12:19 這套架構可以和 Claude 一起做：Claude 會讀文件，幫你找出最適合部署到 Google Cloud 的做法，你本身不需要懂 Google Cloud
  ↳ 重點是你不用先學會 Google Cloud。Claude 會自己讀官方文件，挑出適合的部署方式。部署就是把程式放上雲端讓別人能用。你只要說清楚想要什麼，再判斷結果對不對。
• 12:49 實作細節（例如怎麼部署到 Cloud Run、怎麼把原始紀錄從 file store 讀進 BigQuery）可以用最近推出的 Google Cloud skills，最後不只能設計架構，還能真的部署上去
  ↳ skills 是預先寫好的專門操作說明，讓 Claude 照著做特定任務。Cloud Run 是 Google Cloud 執行應用程式的服務。有了這些 skills，Claude 不只會畫設計圖，還能真的把東西架上去。
• 13:19 用 Claude Code 的 subagent 讓任務平行進行，像一個團隊在跑 sprint：一個 subagent 負責 API，一個負責 BigQuery data pipeline，一個負責 dashboard
  ↳ subagent 是 Claude Code 能派出去分頭做事的小幫手。就像團隊在衝刺期（sprint）分工：一個寫 API（程式之間溝通的窗口），一個弄資料流程，一個做 dashboard，同時進行。
• 13:51 Demo：先把 Claude 連上查文件用的 MCP server，並準備幾個專用的 skills，接著請它用 MCP server 和 skills 設計架構和 API spec
  ↳ MCP server 是讓 Claude 連到外部資源的接頭，這裡先接上一個查文件用的。再準備幾個 skills，然後請 Claude 設計架構和 API spec，也就是 API 的詳細規格書。
• 13:51 Claude 沒被要求提供特定資訊，就自己去查 MCP server，再依照從文件查到的內容建出架構
  ↳ 示範者沒指定要查什麼，Claude 自己判斷該去翻文件，再照查到的內容設計架構。它不是憑印象寫，是有文件根據的。
• 14:21 接著用 skills 產生 API spec：包含不同的 pages、paths，以及很詳細的 API 說明；確認接受後，就有了架構和 API 規格
  ↳ Claude 用 skill 產出 API 規格：有哪些頁面、哪些路徑（網址的哪一段對應哪個功能），每一項都寫得很細。人看過、按下接受，設計階段就完成了。
• 14:21 下一步：用 subagent 平行開發，把整個系統建出來
  ↳ 設計圖和規格都有了，接著交給好幾個 subagent 同時動工，把整個系統做出來。
• 14:51 過程中用了不同的模型和不同的 subagent，速度很快；app 實作完成後還會跑測試
  ↳ 不同 subagent 可以用不同的 Claude 模型，分頭做所以很快。程式寫完不會直接交差，還會自己跑測試，確認能正常運作。
• 14:51 測試跑完後，再用另一個 skill 建立部署到 Google Cloud 需要的所有元件
  ↳ 測試通過後，再用另一個 skill，把部署到 Google Cloud 需要的設定和元件一次建好，不用自己一項一項摸索。
• 15:21 建立 CI/CD pipeline，用到 Google Cloud 的兩個產品：Cloud Build 負責 CI，Cloud Deploy 負責 CD
  ↳ CI/CD pipeline 是自動化流水線。CI 是程式一改就自動組建、檢查；CD 是自動把新版送上線。這裡由 Cloud Build 負責 CI，Cloud Deploy 負責 CD。
• 15:21 完成後會建立 PR 並推到 GitHub；PR merge 之後會觸發 workflow
  ↳ PR（pull request）是「我改好了，請審核後合併」的申請，GitHub 是存放程式碼的平台。PR 被 merge（合併進主程式）之後，自動流程就會啟動。
• 15:57 這個 workflow 就是 Google Cloud 上的 build pipeline，包含 API、dashboard 的各個步驟，最後一步是 release
  ↳ 這裡的 workflow 就是剛剛那條自動化流水線，會依序處理 API、dashboard 等步驟。最後一步產出 release，也就是一個可以上線的新版本。
• 15:57 pipeline 跑完後，會把新 release 推到持續部署工具，再由這個工具觸發 release
  ↳ 流水線跑完後，新版本會交給 Cloud Deploy 這個持續部署工具，由它負責把版本實際放上去。
• 16:28 因為還在開發階段，app 會部署到 development 環境，目前不需要 promotion；app 跑在開場提到的 serverless function 上，UI 和先前展示的一樣
  ↳ development 是內部測試環境，production 是給真正使用者用的正式環境。還在開發就先放 development，不用 promotion（升到正式環境）。app 跑在 serverless 上，意思是不用自己管伺服器。
• 16:58 上 production 之前要先確定程式碼沒問題，所以要做安全審查（security review）；Claude Code 有很多種做法，這裡用的是自訂 plugin
  ↳ 給真人用之前，要先做 security review（安全審查），確認沒有漏洞。Claude Code 有很多種做法，這裡用自訂的 plugin，也就是可以安裝的擴充功能包。
• 16:58 用自訂 plugin 的原因：在真實世界裡，每家公司的安全審查要求都不一樣
  ↳ 每家公司的資安規定都不一樣，通用的檢查不一定符合，所以自己做一個 plugin，把公司的標準寫進去。
• 17:28 可能的檢查項目：部署時檢查 top 10 問題、檢查 app 有沒有不合規的東西；部署在雲端時，要檢查 service account，限制權限和 app 能存取的服務
  ↳ 可以檢查常見的十大安全問題，也可以看有沒有違反規定。service account 是給程式用的帳號，要限縮它的權限，讓 app 只能碰到必要的服務。
• 17:59 這次的審查內容：做 input validation、修改 service account 的權限，最後部署到 production
  ↳ 這次實際做三件事：做 input validation（檢查使用者輸入的內容，擋掉可疑資料）、收緊 service account 的權限，最後上 production。
• 17:59 Demo：定義好 plugin，並用 prompt 描述它要做什麼
  ↳ 先把 plugin 定義好，再用 prompt（給 AI 的文字指令）寫清楚它要檢查什麼、怎麼做。
• 18:30 plugin 開始檢查權限和 input validation，發現問題後幾秒內就改好程式碼、修好 app，再跑一次額外測試
  ↳ plugin 開始檢查權限和輸入驗證，發現問題後幾秒內就改好程式，再多跑一輪測試，確認沒把別的地方改壞。
• 19:01 流程和前面一樣所以很快：開新的 PR、推到 repo；因為通過審查，會 build 並觸發新的 release
  ↳ 修好之後走一樣的流程：開 PR、推到 repo（程式碼倉庫）。通過審查就自動組建、產生新版本。因為流程是固定的，所以很快。
• 19:01 新 release 送到 Cloud Deploy，先部署到 development 環境
  ↳ 新版本進到 Cloud Deploy 後，照規矩先放 development 環境，不會直接上正式環境。
• 19:31 在 development 環境可以再檢查一次 app，最後 promote 並核准上 production；這些用 Cloud Deploy 本身的功能就能快速完成
  ↳ 在 development 再確認一次沒問題，才按 promote、核准上 production。這些步驟用 Cloud Deploy 內建的功能就能快速完成。
• 19:31 從 prototype 出發，用 Claude Code 把 app 部署到 Google Cloud，並照 development／production 的架構分環境
  ↳ 回顧一下：從 prototype（能動的雛形）出發，靠 Claude Code 一路部署到 Google Cloud，還分好測試和正式兩個環境。
• 20:02 最後一步：收集使用指標，例如使用者用這個 app 提供回饋要花多久；花太久可能代表 UI 體驗不夠好，可以改進
  ↳ 上線後要收集使用數據，例如使用者送出一次回饋要花多久。如果花太久，可能代表畫面不好用，就知道該改哪裡。
• 20:33 你可能不知道怎麼在 Google Cloud 做分析，也不熟 BigQuery 和 dashboard 工具，但這不是問題
  ↳ 就算你不會 Google Cloud 的分析工具，也沒碰過 BigQuery 或 dashboard 工具，也沒關係。
• 21:04 Google Cloud 現在有官方 MCP server，可以在 BigQuery 做分析，也能即時建出完整的 dashboard
  ↳ Google Cloud 現在有官方的 MCP server。Claude 接上之後，就能直接在 BigQuery 分析資料，當場做出完整的 dashboard。
• 21:34 開場做的 live dashboard 有整合 Claude 來摘要回饋，但那是給開發團隊自己看的，不能直接交給 PM，所以需要正式的分析
  ↳ 開場那個即時 dashboard 有請 Claude 摘要使用者回饋，但那是給開發團隊自己看的。要交給 PM（產品經理）做決策，就需要正式的分析。
• 21:34 原始資料存在 BigQuery，用 BigQuery MCP server 分析這些資料並產生統計數據
  ↳ Claude 透過 BigQuery 的 MCP server 讀取存在裡面的原始資料，算出統計數字。
• 22:06 統計結果還只在 terminal 裡，PM 不會喜歡；所以用第二個 MCP server 拿這些數字在 Looker 建 dashboard，最後只會拿到一個連結
  ↳ 但這些數字只出現在 terminal（打指令的文字視窗），PM 不會想看。所以再接第二個 MCP server，把數字做成 Looker 報表，最後只給你一個連結。
• 22:06 dashboard 會顯示使用者完成一次 session 要花多久，並比較不同的機率分布，是更適合拿來討論怎麼改進 app 的產出
  ↳ dashboard 顯示使用者完成一次 session（從開始用到做完的一輪）要花多久，並比較幾種時間分布。它比一堆數字更適合拿來討論怎麼改 app。
• 22:36 就算你不懂 dashboard 工具，也能用 Claude Code 加上他們提供的 MCP server 建出這份 dashboard
  ↳ 重點是：不會用 dashboard 工具也沒關係，Claude Code 加上官方的 MCP server 就能幫你做出來。
• 23:06 總結一（Claude Code 這邊）：可以用 plan mode、subagent、MCP、skills、plugin 做出 prototype，並部署到 Google Cloud
  ↳ Claude Code 這邊用到了 plan mode（先讓 Claude 規劃、你確認後才動手的模式）、subagent、MCP、skills、plugin，從雛形一路做到上雲端。
• 23:36 總結二（Google Cloud 這邊）：除了 host 應用程式，也能存取 Claude 模型，讓整個開發過程幾乎沒有阻礙
  ↳ Google Cloud 這邊，不只能 host（放置並執行）你的應用程式，還能直接在上面使用 Claude 模型，整個開發過程幾乎不會卡關。
• 23:36 想做比今天這個回饋 app 更複雜的應用，可以看場次最後分享的 repo、quick start 和文件
  ↳ 想做比這個回饋 app 更複雜的東西，可以去看場次最後分享的 repo、quick start（快速入門教學）和文件。

在 demo 的 CI/CD pipeline 裡，哪兩個 Google Cloud 產品分別負責 CI 和 CD？