安安～我是ChiYu～

前兩天在本機把程式基線與安全防線分開驗過，今天終於把同一份 release 推上 Azure
Container Apps。公開網址回應 200 OK，我差點就可以收工了。

差點而已。

200 OK 只代表某個服務正在回應。它是不是剛才通過測試的 commit，不能靠網址長得一樣
來認親。要把本機結果與公開站接起來，我還缺幾個不太浪漫、但非常好用的座標：這個網址
究竟指向哪個 commit、哪個 image digest、哪個 Azure revision？

先分清楚開發候選版與正式 release

網站功能收斂時的開發候選版是 v3-day-25，commit 為 3a9b124。它適合查看準備發布的
程式狀態：

git switch --detach v3-day-25
npm ci
npm run verify

不過，今天記錄的正式部署證據不屬於這個 candidate。發布前的修正、驗證報告與版本帳本
收斂後，另外建立了 v3-p0-release.1。接下來出現的 commit、image digest、Azure revision
與 workflow run，全都以正式 release 為準，不能拿較早的 v3-day-25 替它背書。

圖 1：每個座標都必須指向同一份 release。只要其中一段無法對齊，公開網站就不能替本機測試升級。

把 source、image 與 runtime 寫進同一份帳本

本系列使用下列座標重播部署：

tag       v3-p0-release.1
commit    8e89e6519406388a0de8c456a890d6fcc8cc5544
digest    sha256:8f43bff7fad16300e6eb534cbacda4f4e1969112da0be2e0997773cff77aee41
revision  ca-agentready-events--0000006
run       30549409859
URL       https://ca-agentready-events.jollyfield-623e719e.eastasia.azurecontainerapps.io

Tag 固定原始碼，完整 digest 固定 container，revision 固定 Azure 執行單位；
/health/version 再把 commit、revision 與公開回應接回來。這條鏈不是為了增加部署術語，
而是避免 main、latest 或一張綠色 workflow 畫面代替實際版本。

最後要能組成這條等式：

原始碼 commit
  = build 使用的 commit
  = immutable image digest
  = Azure revision 使用的 image
  = public URL 實際承接的流量
  = health 與 production smoke 的測試目標

其中任何一段對不上，就只能說「某個版本曾經通過」，不能說公開網站正在跑那一份程式。

Build 成功，不代表公開 revision 已經更新

workflow 由 workflow_dispatch 接收固定 ref 與 deploy 選項。Build job 先執行測試、建立
Linux image、跑 container smoke，再推送以 SHA 標記的 image 並解析 digest。

Deploy job 只有在明確選擇部署時才會執行，透過 GitHub production environment、OIDC 與
Azure what-if 發布 immutable digest。

這裡最容易看錯的是：build job 成功，不等於 deploy job 已執行。若 deploy 仍是 false，
image 可以存在於 registry，公開 revision 卻完全沒有改變。驗收時要一起查看 job condition、
revision name 與 /health/version，不能只截 workflow 頂端的綠色勾勾。

Smoke test 做完，也要把公開狀態收乾淨

第一次 production Journey smoke 完成報名後，公開活動的剩餘名額從 8 變成 7。測試本身
通過，環境卻被測試資料污染；下一位讀者看到的狀態已經不同。

修正後，每個會變更名額的 smoke 都在同一個 session 完成反向操作：

報名前 remainingCapacity = 8
報名後 remainingCapacity = 7
取消後 remainingCapacity = 8

revision 0000006 的完整 smoke 結束後，名額恢復為 8。這個案例提醒我：部署測試不能只驗證
「做得到」，還要檢查「測完留下什麼狀態」。

正式系統通常應使用獨立測試 tenant、可回復交易或隔離資料；這個 Demo 的單一 Node.js
記憶體 inventory，只是目前可重播的產品邊界。

本機測試與公開部署，證據等級不同

固定 tag 的驗證結果如下：

這些結果由 test harness 執行，因此仍屬 E2。當精確 commit、digest、revision、公開 HTTPS、
/health/version、production smoke 與 Chrome capability 對齊後，才能把這個 release 的
公開 runtime 標到 E3。

我用三個位置交叉核對：

1. 從 tag v3-p0-release.1 建立乾淨 clone，執行 npm ci 與 npm run verify，記下完整
   commit SHA。
2. 核對 workflow run 30549409859 的 ref、image digest、deploy job、Azure revision 與
   public FQDN。
3. 從公開網址檢查 /health/version、API 與三條 Human-first Journey；確認 smoke 結束後
   名額仍回到 8，再將 runtime integration 標為 E3。

這三步回答的是「哪份程式正在公開環境執行」，不是「模型會不會使用它」。

我選完整 digest，不用方便但會移動的 latest

latest 很適合快速取得映像，卻無法在幾天後回答「當時測的是哪一份程式」。完整 digest
難讀一些，但它能讓 source、CI artifact、Azure revision 與後續 Inspector session 被同一份
帳本串起來。

對需要評審、讀者或另一位工程師重播的作品，可查核性比 tag 好看更重要。

到這裡仍然沒有自然語言 Agent 證據

E3 證明固定 release 在公開 HTTPS runtime 可用，而且相容 Chrome 能看到網站提供的 WebMCP
capability。它不證明 Gemini 會理解 Prompt、選對 Tool 或完成 Journey；手動指定 Tool 也不能
升成 E4。

版本鏈對齊後，明天才在固定公開 revision 送出自然語言。先重播兩個唯讀任務：「搜尋活動」
與「目前活動」。這一次不只截 Inspector；Prompt、Tool call、result、answer 與部署座標都要
一起留下，免得幾天後只記得「那次好像有成功」。

參考資料

• Microsoft Learn：Deploy Azure Container Apps with GitHub Actions
• Microsoft Learn：Manage revisions in Azure Container Apps
• Chrome：WebMCP Evals