軟體開發生命週期 (SDLC)

雲端環境下的 SDLC 簡介

軟體開發生命週期 (SDLC) 是一個定義軟體開發過程中各個步驟任務的框架。對於專業雲端架構師 (Professional Cloud Architect) 而言，SDLC 不僅僅是編寫程式碼，更在於建構一個能讓程式碼安全、快速且可靠地從開發者的筆記型電腦遷移到全球生產環境的系統。

在雲端環境中，傳統的「瀑布式 (Waterfall)」模型在很大程度上已被敏捷 (Agile) 和 DevOps 實踐所取代，這些實踐縮短了回饋循環，且自動化至關重要。

白話文解釋（Plain English Explanation）

比喻 1 — 主廚的食譜 (敏捷 SDLC)

在瀑布式模型中，廚師花費數月編寫一套 10 道菜的菜單，一次煮好後端給顧客，顧客卻可能發現他們對第一道菜過敏。在敏捷 SDLC 中，廚師先準備一道開胃菜，端給顧客並詢問：「你喜歡這個鹹度嗎？」，然後根據該回饋來烹飪下一道菜。重點是用小而可食用的增量逐步堆疊出完整套餐——這正是 Cloud Build 觸發器、Artifact Registry 推送與 Cloud Deploy 部署，一次驗證一個變更的方式。

比喻 2 — 汽車組裝線 (CI/CD 流水線)

將 SDLC 想像成一條組裝線。持續整合 (CI) 就像是在旋緊每個螺栓時都會進行檢查的自動化機器人，以確保螺栓沒有滑牙。持續部署 (CD) 則是能自動將完工的汽車駛離生產線並進入經銷商展示廳的系統，因為它通過了每一項品質檢查，無需人類逐一簽核。在 GCP 上，Cloud Build 是那個機器人；Artifact Registry 是倉庫；Cloud Deploy 是把車送到經銷商（GKE、Cloud Run 或 GKE Enterprise）的貨車。

比喻 3 — 機場安檢站 (安全性左移)

傳統安全性發生在 SDLC 的最後階段（登機門）。安全性左移 (Shift Left Security) 就像是在停車場入口和報到櫃檯就設置了安全掃描器。透過在旅程早期捕捉到「違禁品」（臭蟲或漏洞），您可以避免飛機（程式碼）即將起飛前才發現問題所造成的巨大延遲和成本。Pre-commit hook 的 SAST、推送時的 Artifact Analysis、部署時的 Binary Authorization 構成三道循序的關卡，每一道的修復成本都遠低於下一道才抓到問題的代價。

SDLC 方法論：傳統 vs. 雲端原生

Google Cloud 中的關鍵 SDLC 階段

1. 規劃與分析

• 工具： Cloud Architecture Framework、價格計算機。
• 重點： 識別業務需求和技術限制（SLA、RTO/RPO）。

2. 設計與原型製作

• GCP 情境： 在 GKE（容器原生）、App Engine (PaaS) 與 Cloud Run（無伺服器）之間做出選擇。
• 基礎設施即程式碼 (IaC)： 使用 Terraform 或 Config Connector 以程式碼定義「原型」。

3. 開發與測試

• 左移： 開發人員使用 Cloud Code 等工具針對本地環境的 GCP API 進行測試。
• 容器化： 使用 Docker/Buildpacks 確保解決「在我的機器上可以執行」的問題。

4. 整合與部署

• Cloud Build： 編譯與測試程式碼的引擎。
• Artifact Registry： 存放建置成品的安全倉庫。
• Binary Authorization： 確保只有經過「證實 (attested)」（簽署並驗證）的映像檔才能在 GKE 中執行。

DORA 指標：衡量 SDLC 健康度

Google 的 DORA (DevOps Research and Assessment) 團隊辨識出四項關鍵指標，將「菁英 (Elite)」表現團隊與「低度 (Low)」表現團隊區分開來。身為 PCA，您必須設計能在這四項指標上帶來可量測改善的平台。

四項關鍵指標

1. 部署頻率 (Deployment Frequency) — 程式碼到達生產環境的頻率。菁英團隊隨需部署（一天多次）；低度團隊每月不到一次。可將 Cloud Deploy rollouts 或 Cloud Build 觸發成功次數匯出至 BigQuery 來追蹤。
2. 變更前置時間 (Lead Time for Changes) — 從 commit 到生產環境的時間。菁英團隊：不到 1 小時；低度團隊：1–6 個月。以 Cloud Build duration 加上 Cloud Deploy rollout 時間，依 commit SHA 串接計算。
3. 變更失敗率 (Change Failure Rate) — 造成生產環境失敗（rollback、hotfix、incident）的部署比例。菁英：0–15%；低度：46–60%。由 Cloud Deploy ROLLED_BACK 狀態相對 SUCCEEDED 的比例計算。
4. 平均修復時間 (MTTR) — 生產事件後恢復服務所需時間。菁英：不到 1 小時；低度：超過 6 個月。透過 Cloud Monitoring SLO burn-rate 告警餵給 PagerDuty 加上 Cloud Deploy 的自動 rollback 來壓低數字。

在 GCP 上的實作

• 透過 Pub/Sub log sinks 將 Cloud Build 與 Cloud Deploy 事件匯出至 BigQuery。Schema 包含 build_id、commit_sha、start_time、end_time、status。
• 使用 Looker Studio 儀表板讀取 BigQuery，按服務、按週渲染四項 DORA KPI。
• 交叉比對 Cloud Logging 事件紀錄（以 severity=ERROR 與 incident_id 篩選），用以計算變更失敗率與 MTTR。

在 Cloud Source Repositories / GitHub 上的 Trunk-Based Development

主幹開發 (Trunk-Based Development, TBD) 是 Google 內部工程與 DORA 研究所偏好的分支模型。每位開發者每天至少向單一長存分支（main/trunk）提交一次；長存的 feature branch 被完全消除。

為什麼用 Trunk-Based？

• 消除 merge hell — 長存的 feature branch 會與主幹漂移並產生痛苦的衝突。TBD 維持整合是持續進行的。
• 更緊密的回饋循環 — Cloud Build 對每次推送到 main 觸發，因此問題能在數分鐘內被抓到。
• 賦能持續交付 — 因為主幹永遠可發佈，每次 commit 都是一個 release candidate。

在 GCP 上實作 TBD

1. 分支保護 — 在 Cloud Source Repositories 或 GitHub 上，要求合併到 main 前須有 PR、通過狀態檢查（Cloud Build 綠燈）、且至少一名審核者核准。
2. Cloud Build 觸發器設定 — 定義一個 Push to a branch 類型觸發器匹配 ^main$，加上一個 Pull request 觸發器做合併前驗證。
3. 短命 feature branch — 分支應只活幾小時，而非數週。24 小時內合併或刪除。
4. 以 Feature Flag 隱藏未完成的工作 — 尚未完成的程式碼以關閉的 flag 上線；主幹保持可發佈。

Trunk-Based vs. GitFlow

對於大多數運行在 GKE/Cloud Run 上的雲端原生服務，Trunk-Based 勝出。GitFlow 只有在您交付可安裝軟體並同時支援多個版本（例如地端設備）時，才值得它的複雜度。

用 Firebase Remote Config 做 Feature Flag

Feature flag 將部署（binary 上線到主機）與發佈（功能對使用者可見）解耦。同一個 Cloud Run revision 可以根據 flag 狀態，向不同使用者區隔提供不同功能組合。

Firebase Remote Config 作為 Flag Store

Firebase Remote Config 是 GCP 受管的 feature flag 平台。參數為 key/value 配對，並可帶條件值，可在伺服器端或經由 Firebase SDK 在客戶端評估。

// 在 Cloud Run 服務中做伺服器端 flag 判斷
const remoteConfig = admin.remoteConfig();
const template = await remoteConfig.getServerTemplate();
const config = template.evaluate({ userId, country, planTier });
if (config.getBoolean('new_checkout_flow_enabled')) {
  return renderNewCheckout();
}
return renderLegacyCheckout();

SDLC 中的 Flag 模式

• Release flag — 對 1% 使用者開啟功能，監看 Cloud Monitoring SLO，再逐步擴增到 10% → 50% → 100%。
• Ops flag — 事件期間瞬間關閉昂貴功能（kill switch），不必重新部署。
• Experiment flag — A/B 測試變體，可整合 Google Analytics 4 / Firebase A/B Testing。
• Permission flag — 以使用者層級或 allow-list 限制 beta 功能。

治理

• 經由 Cloud Audit Logs 稽核 flag 變更（Remote Config 寫入會出現在 Data Access logs 中）。
• 設定 flag 生命週期政策 — release flag 應在 100% 全量發佈後 30 天內移除，以防 flag debt。
• 高風險功能可將 flag 與 Cloud Deploy 核准關卡結合：先以關閉狀態部署，再在人工核可後翻轉 flag。

安全性左移：在 Cloud Build 中執行 SAST 與 SCA

安全性左移把漏洞偵測推進到開發者的內循環（inner loop），此時修復成本最低。靜態應用程式安全測試 (SAST) 掃描原始碼中的漏洞（SQL injection、XSS、硬編碼祕密）。軟體組成分析 (SCA) 掃描相依套件的已知 CVE。

在 Cloud Build 中整合 SAST

# cloudbuild.yaml
steps:
  - name: 'returntocorp/semgrep'
    args: ['semgrep', '--config=auto', '--error', '.']
  - name: 'gcr.io/cloud-builders/gcloud'
    args: ['secrets', 'versions', 'access', 'latest', '--secret=sonar-token']
  - name: 'sonarsource/sonar-scanner-cli'
    args: ['-Dsonar.projectKey=my-app']

只要任一 SAST 步驟以非零碼結束，整個 build 即失敗——成品永遠不會被推送到 Artifact Registry。

經由 Artifact Analysis 進行 SCA

Artifact Analysis（前身為 Container Analysis）會自動掃描每一個推送到 Artifact Registry 的映像檔，比對 Google 維護的漏洞資料庫（來源包含 NVD、Debian、Ubuntu、Alpine 等）。

• 結果會顯示在 Artifact Registry UI，並以串流方式送往 Pub/Sub 供自動化使用。
• 使用 Cloud Build + gcloud artifacts docker images list-vulnerabilities 來阻擋任何含 CRITICAL CVE 的映像部署。
• Binary Authorization 政策可要求映像在部署到生產 GKE 叢集之前必須先具備 vulnerability-attestor 的證實。

祕密掃描

• Secret Manager 存放祕密；切勿將祕密提交到 repo。
• Cloud Source Repositories 與 GitHub 都會掃描已知的憑證樣式（AWS 金鑰、Google 服務帳號 JSON 等），偵測到即告警。
• 在 Cloud Build 的 pre-commit 步驟啟用 gitleaks 作為縱深防禦。

GKE 上的測試金字塔

測試金字塔 (Mike Cohn) 主張：底層為大量快速的單元測試，中段為較少的整合測試，頂端為少量的端對端測試。倒金字塔（「冰淇淋甜筒」）則又慢又脆。

將金字塔對應到 GCP 服務

GKE 上的臨時測試環境

一個 PR 觸發 Cloud Build：

1. 建置映像並推送至 Artifact Registry。
2. 使用 kubectl apply 或 Cloud Deploy（以 per-PR target）部署到名為 pr-<number> 的新 GKE namespace。
3. 對該 namespace 跑整合與 E2E 測試。
4. PR 關閉時，透過 GitHub webhook → Cloud Function → kubectl delete namespace 拆掉 namespace。

測試資料管理

• 整合測試使用 Spanner emulator 或專屬測試資料庫；切勿與生產環境共用狀態。
• 資料密集型測試可快照生產資料、透過 Cloud DLP 去識別化，再載入到測試用的 Cloud SQL 實例。

環境管理策略

成熟的 SDLC 需要隔離環境，以防止「實驗性」程式碼影響真實客戶。

1. 開發 (Dev)： 開發人員進行嘗試的地方。權限較鬆。
2. 測試/QA： 自動化單元測試與整合測試。
3. 預發佈/UAT (使用者驗收測試)： 生產環境的鏡像，用於最終簽核。
4. 生產 (Prod)： 關鍵任務環境。嚴格的 IAM、VPC Service Controls 和監控。

環境一致性：讓 Dev、Staging、Prod 對齊

環境漂移 (environment drift) 是 SDLC 速度的隱形殺手：程式碼在 staging 可用，到了 prod 卻爆掉，因為兩邊在某些細節（runtime 版本、祕密、網路規則、資料規模）上有所不同。

Twelve-Factor 一致性原則

1. 所有環境同一版本 — 跨環境晉升的容器映像必須位元相同（相同 SHA digest）。從同一個 Artifact Registry repo 以 @sha256:... 形式拉取。
2. 同一組後端服務 — 若 prod 用 Cloud SQL，staging 也該用——不能改用 SQLite。低階環境可採用較小機型，但不可使用不同產品。
3. 同一套設定機制 — 所有環境差異值都從 Secret Manager 與環境變數讀取，不要寫死進映像裡。

以 IaC 打造可重現環境

• Terraform 模組以環境為參數——每個環境的模組將 var.env = "prod" 傳入共用的 service-platform 模組。
• Config Connector 讓您以 Kubernetes manifest 表達 GCP 資源，可透過同一個 kubectl apply 流程依環境部署。
• Cloud Foundation Toolkit 提供預製的 Terraform blueprints，在所有環境間強制執行組織層級的標準。

常見一致性缺口與修補

晉升模式

晉升的是成品，不是原始碼。一次建置的映像 SHA 沿著 build → dev → staging → prod 流動。Cloud Deploy 透過鎖定成品的 release 物件與代表環境的 target 物件，原生強制這個模式。

透過 Config Sync 實作 GitOps

GitOps 將 Git repository 視為應用程式與基礎設施狀態的唯一可信來源。控制器持續地將實際叢集調諧 (reconcile) 到與 repo 一致。

Config Sync 架構

Config Sync（屬於 GKE Enterprise / Anthos Config Management）是 Google 受管的 Kubernetes GitOps 控制器。

1. 叢集營運人員將 YAML/Kustomize/Helm manifest 提交到 Cloud Source Repository 或 GitHub。
2. 每個 GKE 叢集上的 Config Sync operator 輪詢該 repo（預設 15 秒），並套用任何漂移。
3. Policy Controller（建構於 OPA Gatekeeper 之上）在合併之前就擋下不合規的 manifest——將組織政策當作程式碼來強制。

多環境 GitOps 的 Repo 結構

config-repo/
  base/                     # 共享 manifest
    deployment.yaml
    service.yaml
  overlays/
    dev/kustomization.yaml  # 對 base 做 dev 的 patch
    staging/kustomization.yaml
    prod/kustomization.yaml

每個叢集的 RootSync 資源指向特定的 overlay 目錄。

對 SDLC 的好處

• 可稽核 — 每次叢集變更都有 Git commit 作者與 PR 審核軌跡。
• 可逆 — git revert 即可回退任何變更；Config Sync 在數秒內重新收斂。
• 災難復原 — 叢集毀了？開一個新的 GKE 叢集，把 Config Sync 指向同一個 repo，看著它自我修復回期望狀態。
• 漂移偵測 — 手動 kubectl edit 的改動會自動被還原（或依 RootSync 模式被標記出來）。

與推送式部署的比較

Cloud Code IDE 工作流程

Cloud Code 是 Google 的 IDE 擴充功能（VS Code、IntelliJ、Cloud Shell Editor），把雲端原生開發的內循環帶到開發者的筆記型電腦上。

內循環能力

• 本地 Kubernetes 開發 — 從 IDE 內就能啟動 minikube、kind 或 Cloud Run 模擬器。底層用 Skaffold 做熱重載迭代。
• Cloud Run 預覽 — 不離開編輯器就能建置、部署並除錯一個 Cloud Run 服務。
• YAML schema 驗證 — 對 Kubernetes、Skaffold 與 Cloud Build YAML 提供即時 lint 與內嵌文件。
• Secret Manager 整合 — 在程式碼中以自動完成方式參照祕密；不必複製貼上祕密值。

Skaffold 驅動的循環

# skaffold.yaml
apiVersion: skaffold/v4beta7
kind: Config
build:
  artifacts:
    - image: us-central1-docker.pkg.dev/my-proj/repo/my-app
      sync:
        manual:
          - src: 'src/**/*.js'
            dest: /app/src
deploy:
  kubectl:
    manifests:
      - k8s/*.yaml

skaffold dev 監看原始碼樹，變更時重新建置映像並重新部署到指定叢集——程式碼變更的回饋循環在 30 秒以內。

在雲端中除錯

• Cloud Code Debug 將 IDE 除錯器附掛到遠端 GKE 叢集中執行的容器化行程——在筆電上設中斷點，程式卻跑在 pr-123 namespace 裡。
• Cloud Logging 整合 — 將 pod log 串流到 IDE 的 Output 面板，可依嚴重度過濾，並在錯誤行直接跳到原始碼。

Cloud Code 在 SDLC 中的定位

Cloud Code 是內循環工具（寫程式 → 本地測試 → 重複）。一旦 commit，外循環（Cloud Build → Artifact Registry → Cloud Deploy → GKE）就接手。健康的 SDLC 會讓內循環又快（秒級），外循環又全面（關卡、測試、掃描）。

SDLC 中的安全性 (DevSecOps)

安全性不應是一個獨立階段，而應整合到每個步驟中：

• 靜態分析 (SAST)： 在程式碼提交「之前」掃描其中的祕密（API 金鑰）和漏洞。
• 動態分析 (DAST)： 測試執行中應用程式的缺陷。
• 軟體供應鏈安全： 使用 Artifact Analysis 掃描容器映像檔中已知的 CVE。

部署後驗證

部署不是在 rollout 回報成功時就算完成——而是在生產環境的遙測資料確認新版本符合 SLO 時，才算真正完成。

Rollout 後的 Smoke Test

當 Cloud Deploy 將一個 release 晉升到 target 之後，執行部署後驗證工作：

# clouddeploy.yaml
serialPipeline:
  stages:
    - targetId: prod
      deployParameters:
        - values:
            verify: true
verify:
  - name: smoke-tests
    skaffoldConfig: skaffold-verify.yaml

該工作呼叫關鍵 endpoint（/healthz、/api/v1/checkout），若回應非 200 或延遲超過 SLO，則該 release 失敗。

以 SLO 為基礎的驗證

• 在 Cloud Monitoring 中定義 服務水準目標 (SLO)（例如：滾動 1 小時內 99.5% 可用性）。
• 部署完成後，觀察 error budget 燒蝕率 (burn rate) 15 分鐘。若燒蝕率超過正常值 2 倍，Cloud Deploy 自動 rollback。
• 將 burn-rate 告警接到 PagerDuty，用於自動 rollback 不安全時（例如帶資料遷移的部署）的人工升級。

合成式監控

• Cloud Monitoring Synthetic Monitors 每分鐘從多個 Google PoP 執行腳本化的 Playwright/HTTP 檢查。
• 設定為當新版本上線、且關鍵使用者旅程中斷時告警——抓出單元測試抓不到的問題。

用 Cloud Deploy Canary 做漸進式交付

Cloud Deploy 支援 canary 策略，能自動化部署後驗證：

strategy:
  canary:
    runtimeConfig:
      kubernetes:
        serviceNetworking:
          service: my-service
    canaryDeployment:
      percentages: [10, 50]
      verify: true

流量先切換到 10%，驗證執行，再切到 50%，再驗證，最後 100%。任何失敗都會觸發自動 rollback 到先前的穩定 revision。

閉環

部署後資料會回饋進 SDLC：失敗的 canary 變成回歸測試；SLO 違規衍生出 Jira 工單，推動下一個 sprint 的可靠性工作。SDLC 不是一條直線——而是一個循環。

常見問題 — 軟體開發生命週期

Q1. 如果我們有自動化測試，為什麼還需要「預發佈 (Staging)」？

自動化測試（單元/整合測試）檢查的是邏輯，但預發佈檢查的是環境一致性 (Environment Parity)。它確保應用程式能在真實的生產環境網路配置、資料庫規模和 IAM 角色下運作。

Q2. PCA 角色如何融入 SDLC？

架構師負責設計支援 SDLC 的平台。您不一定要編寫程式碼，但您要設計 CI/CD 流水線、IAM 結構和部署策略（例如藍綠部署）。

Q3. 藍綠部署與金絲雀發佈有什麼區別？

藍綠部署在完全測試後，將 100% 的流量從舊版本（藍色）切換到新版本（綠色）。金絲雀發佈則逐漸轉移小部分百分比的流量（例如 5%，然後 20%），以便及早發現問題並將對使用者的影響降至最低。

Q4. Dev 和 Prod 應該放在同一個 GCP 專案中嗎？

絕對不要。 它們應該放在獨立的專案中，理想情況下是獨立的資料夾，以確保完整的資源隔離並防止資料意外「交叉污染」。

Q5. 什麼是 "Binary Authorization"？

這是一種針對 GKE 的部署時安全性控制。它確保只有經過建置流程簽署（且通過安全性掃描）的容器映像檔才被允許部署到生產環境。

最後的架構師提示

在 PCA 考試中，如果問題提到「縮短上市時間」或「提高可靠性」，請尋找涉及自動化、CI/CD 和小規模發佈週期的答案。如果問題關於「安全性」，請優先考慮安全性左移、成品掃描 (Artifact Scanning) 和 Binary Authorization。始終提倡基礎設施即程式碼 (IaC)，以確保環境是可重現且有文件記錄的。