在推動 Pipeline as Code 的過程中，我原本只想解決一個看似單純的問題：當應用程式從 DEV、SIT 進入 UAT 與 PROD，散落在各個 Kustomize Overlay 中的大量 `secret.yaml`，究竟要如何被整理、建立、填值與部署？

真正困難的並不是 Secret 應該放在 Azure DevOps Library，還是 Azure Key Vault，而是每一次交付都必須在開發者、持密者與雲端基礎設施管理者之間反覆換手。開發者先整理需求，基礎設施人員再將需求翻譯成 Portal 操作、CLI 指令或 IaC；持密者接手後，還可能因 Secret Key、環境或資源位置不一致而產生新的摩擦。當單一領域在一個環境就可能出現數十份 `secret.yaml` 時，這種依賴人工理解與轉譯的流程，很快就無法承受規模。

我沒有完整的平臺團隊，也不可能為此先導入 Backstage。於是，我選擇使用開發者每天最熟悉的 Azure DevOps Repos、Pull Request 與 Pipeline 作為平臺入口，並以 Bicep 主模板封裝 Azure Key Vault、Secret Container、IAM、Tag 與資源配置的複雜度，讓開發者只需要填寫如同結構化表單的 `bicepparam`。

這份參數檔不再是一張需要由另一個人重新解讀的申請單，而是一份可以版本控制、審查、自動驗證並直接執行的宣告式換手契約。Pull Request Pipeline 透過 Azure Validate 與 What-if 提供審查證據，合併後則自動建立資源。開發者可以使用熟悉的 Git 與 Pull Request 流程提出需求，審核者也不必依靠記憶逐項找錯，而能根據自動化結果判斷是否放行。

不同環境則以 IAM 與 Service Connection 切分權限。開發者可以在 DEV、SIT 親自操作與填入 Secret Value；在 UAT、PROD 則只能查看 Secret Key 與 Metadata，無法取得真正的 Value，由持密者完成填值。這項設計讓 IAM 不只是限制存取的安全護欄，也成為一條學習路徑：開發者先在低風險環境理解持密者的操作視角，未來才能更精確地描述需求與協助跨角色合作。

然而，第一版上線後並不完美。我們陸續遇到 `bicepparam` 檔名與 Key Vault 名稱不一致、資源進入錯誤環境、分支未基於最新 Main、必要 Tag 遺漏，以及重複宣告 Secret 可能影響既有 Value 等問題。這些錯誤沒有停留在「提醒使用者下次注意」，而是被逐步轉換成新的 Pipeline 檢查、Azure Policy 與審查證據。

使用者也回饋，大量 Secret 若需要逐筆填入，開發者與持密者都將承受新的操作負擔。因此，平臺又長出了共用的取框與填密工具：先依照 Key Vault 中既有的 Secret Key 產出不含 Value 的 JSON 或 YAML 框架，再由具備適當 IAM 權限的使用者批次填入。工具後續也因特殊字元與 JSON 跳脫問題，增加偵測機制及 YAML 格式，並持續更新 README、ADR 與 Changelog。

這些護欄與工具並不是在第一版架構中一次規畫完成，而是在「投入使用、發現問題、接收回饋、補強護欄、再次投入使用」的循環中逐漸形成。我們也透過早期合作團隊，在規模仍小、錯誤仍容易控制時，快速驗證流程並修正產品。

一個月內，近百座 Azure Key Vault 透過這條路徑被建立。過去需要由基礎設施人員逐筆接收表單、重新理解需求並轉換成雲端操作的工作，逐漸成為開發團隊可以自助使用，同時維持透明度、可稽核性與可追蹤性的平臺能力。

我原本以為這只是 CD 範本、自動化流程與幾項工具的組合，後來才理解，它已經具備 Self-service、Golden Path 與 Platform as a Product 的特徵。這場分享將透過這段從換手問題、MVP、真實錯誤到護欄演進的實作歷程，探討如何不先建立新的 Portal，而是在既有的開發者工具中，讓一項基礎設施能力逐漸產品化，並成長為組織可以重複使用的黃金路徑。

聽完這場分享，聽眾將可以：

1. 1. 理解如何從價值流中的等待、翻譯與跨角色換手問題，辨識適合被產品化的平臺能力，而不只是將既有人工流程直接自動化。
2. 了解如何利用既有的 Repository、Pull Request、Pipeline 與 IaC，建立不依賴新 Portal 的 Self-service 入口，並將參數檔轉化為開發者與平臺之間可審查、可執行的宣告式契約。
3. 學習如何組合 Azure Validate、What-if、Pipeline Check、Azure Policy、IAM 與 Service Connection，在降低人工審查負擔的同時，維持安全性、透明度、可稽核性與可追蹤性。
4. 重新思考 IAM 的用途：除了最小權限與環境隔離，也能透過 DEV、SIT 的安全試錯空間，建立開發者理解其他角色工作視角的學習路徑。
5. 帶走一套讓 Golden Path 持續演進的方法：從早期使用者的真實錯誤與操作回饋中，判斷問題應由文件、工具、Pipeline、Policy 或 IAM 哪一層承接，並將一次性的經驗轉換成下一位使用者可以重複使用的產品能力。