本次 2.0 改版核心在於引進全新層級的架構編排能力，並同步強化組織身分治理、安全合規與多環境遷移的流暢度，提供具備高擴充性的維運管理平台。

Terraform Enterprise 2.0 重點更新

當基礎架構隨著業務規模拆分為多個配置檔案後，團隊耗費大量人工協調彼此的依賴關係、管理部署順序，並重複在不同環境中複製相同的架構。

Terraform Enterprise 2.0 引入了「Stacks」能力，改變了多層級、多環境的部署模式：

• 系統化集中管理： Stacks 允許團隊將分布於不同環境、區域與雲端帳號的基礎架構，視為單一系統進行定義與管理。
• 自動化依賴管理： 系統會自動處理不同架構元件之間的依賴關係與先後順序，減少跨團隊溝通成本。
• 確保部署一致性： 透過將編排能力內建於平台中，企業能以可重複的方式快速擴展環境，消除人為操作引發的配置落差。

專案級通知管理

在過去的運作模式中，維運團隊針對每個獨立的工作區逐一設定通知條件。這在多團隊的大型企業中帶來了顯著的管理負擔，且新建立的工作區容易因漏設通知，導致團隊未能及時收到告警。

Terraform Enterprise 2.0 導入的專案級通知（Project-level notifications）機制優化了這項流程。

管理團隊現在只需在「專案層級」定義一次通知設定，該專案下所有既有及未來新創的工作區皆會自動繼承。這種繼承式管理模型建立了一個中央控制平面，確保所有環境納入合規的監控基線中，消除人為疏漏造成的管理盲點。

SCIM 2.0 身分治理

Terraform Enterprise 2.0 針對身分驗證與權限控管進行了全方位升級，協助企業在實施自助服務的同時兼顧嚴格控管。

在身分同步方面，平台支援了 SCIM 2.0 標準協議，與企業現有的身分驗證中心（目前支援 Okta 與 Azure Entra ID）直接連線。當員工職務變動時，其權限將自動即時同步或註銷，免除手動管理的資安風險。

此外，為了降低長期憑據外洩所帶來的潛在威脅，新建立的 API Token 引入了生命週期管理，全面強制實施過期機制（預設最長兩年）。

新版也提供更精準的權限委派控管，允許特定團隊在定義的範圍內，自行覆蓋未通過的軟性策略檢查。

最後，平台新增了專為資安稽核設計的「站點審計員」唯讀角色，此角色可完整檢視組織運行狀態與策略設定，但會自動屏蔽狀態檔案等敏感數據，確保稽核流程安全合規。

跨組織工作區遷移

為簡化平台的維護工作並強化系統韌性，2.0 版本優化了底層管理工具，包含內建的升級前驗證檢查，可在執行平台升級前主動識別潛在的相容性問題，降低升級中斷的風險。

當企業因組織架構調整需要移動工作區時，新版提供了原生的非同步遷移 API，讓基礎架構的搬移過程更加安全合規。系統在移轉期間會自動鎖定來源端工作區，並在目標端建立新工作區以完整複製狀態版本等關鍵數據。

團隊可在目標環境完成驗證測試後再正式過渡，此時系統會自動重新對應（remap）原始外部 ID 並刪除來源端，確保生產系統與架構狀態在遷移期間完全不中斷。

推薦閲讀：Terraform 資源搜尋與匯入教學：自動生成代碼，完成 IaC 遷移

IBM 支援週期政策

Terraform Enterprise 2.0 起將全面採用 IBM Support Cycle-2 政策，為企業引進更清晰、可預測的軟體生命週期規劃。

在此全新模式下，每個主要版本將獲得至少兩年的標準支援。

在此之後，企業可選擇延長支援：第三年將持續提供關鍵錯誤修復、使用支援與特定的安全性更新；第四至第六年則提供使用指引與已知問題協助。此一穩健的支援架構，將為企業的關鍵任務工作負載提供更具延續性的維運保障。

結語

Terraform Enterprise 2.0 的發布，標誌著現代企業在管理複雜雲端架構時的重要里程碑。

從全新 Stacks 功能帶來的多環境集中編排，到專案級通知與 SCIM 2.0 所構建的資安合規防線，新版平台不再只是協助團隊編寫基礎架構代碼（IaC），而是全方位重塑了大跨度、多團隊環境下的維運治理模式。

隨著平台支援週期的標準化，企業在邁向大規模雲端維運的過程中，將能擁有更穩健、安全且高效率的現代化管理基石。

本文翻譯自：Terraform Enterprise 2.0: Evolving infrastructure operations for scale

想瞭解更多？歡迎聯絡我們，或是 加入歐立威 Line 好友！

雖然 Terraform 已成為基礎架構佈署的標準，但如何將散落在各處、未受控的舊有資源納入管理，一直是維運團隊的挑戰。為了解決碎片化流程，Terraform 1.14 版本推出了 搜尋 (Search) 與 批量匯入 (Bulk-import) 功能。

這項新工作流不只協助企業盤點雲端環境中未受託管的資源，更直接將其導入自動化的安全流程中。以下將透過實際案例，說明 Terraform 如何簡化資源匯入的繁瑣過程。

為什麼需要 Terraform 資源搜尋功能？

目前的雲端環境極其複雜，根據統計，高達 97% 的企業在管理基礎架構時面臨挑戰，且需解決預算超支的問題。其中，「混合雲與多雲環境」的營運複雜度，被公認為是目前最大的技術阻礙。

具體來說，維運團隊常遇到以下問題：

解決手動操作 (ClickOps) 的管理漏洞

直接在雲端控制台手動點選（ClickOps）產生的資源，因為繞過了 IaC 流程，缺乏版本控制與自動化，成為資安治理與成本控制的盲點。

解決雲端資源浪費與閒置風險

缺乏統一盤點工具會導致測試環境、閒置虛擬機或過期儲存空間被遺忘。這些「孤兒資源」大幅增加非必要支出，更因為設定過期或錯誤，成為駭客入侵的資安破口。

解決設定偏移隱患

當雲端資源的實際狀態與預期代碼不符，即產生「設定偏移」。若資源未透過 IaC 管理，偏移將變得不可控，並引發以下風險：

• 資安威脅： 未被追蹤的變更可能成為攻擊者的入侵破口。
• 營運中斷： 意外的設定變動會導致部署失敗或服務停機。
• 合規風險： 稽核員無法確認實際環境是否符合公司政策或安全標準。

解決政策執行與自動化治理的缺失

缺乏 IaC 的環境無法建立防護欄（Guardrails）或自動化合規檢查，因此容易繞過安全控制，增加營運風險並喪失環境可視性，進而造成違反法規或不符產業標準的情況。

Terraform Search 如何解決管理難題？

Terraform Search 支援 HCP Terraform 介面、版本控制系統 (VCS) 或 CLI 工作區，有效解決上述痛點。操作邏輯簡單：

• 定義查詢： 在設定檔中使用 list 區塊定義查詢條件，主動搜尋雲端環境中的現有資源。
• 自動生成代碼： 透過 terraform query 指令，自動產出匯入所需的 resource 與 import 區塊。
• 一鍵納管： 將產出的代碼複製到 main.tf 並執行 terraform apply，即可完成資源匯入。

這套工作流取代了過去耗時且容易出錯的手動匯入（terraform import）流程，實現更安全、可重複利用的自動化管理。

案例：透過 Terraform Search 匯入 AWS EC2 資源

本範例將示範如何搜尋並匯入已存在於 AWS 控制台、但尚未納入 Terraform 狀態檔（State）管理的 EC2 實例。目標是消除管理斷層，將資源統一納入 Terraform 管理。

若使用 HCP Terraform（版本 1.14 以上），可以在左側選單看到新增的 「Search & Import」 選項。本案例將以 CLI 操作為主，示範匯入流程所需的 HCL 代碼。

HCP Terraform 工作區中的「搜尋與匯入 (Search & Import)」功能介面

透過 search.tfquery.hcl 檔案內的 list 區塊 來定義查詢條件。此區塊包含兩個核心參數：指定執行查詢的 Provider，以及用來建構查詢條件的 config 區塊。

search.tfquery.hcl

list "aws_instance" "unmanaged" {
  provider = aws
 
  config {
    region = "us-east-2"
 
    filter {
      name   = "tag:ManagedBy"
      values = ["unmanaged"]
    }
 
    filter {
      name   = "instance-state-name"
      values = ["running"]
    }
  }
}

此範例透過 Terraform 搜尋 AWS us-east-2 區域中，所有標籤為 ManagedBy: unmanaged 的執行中 EC2 實例。

提示： 查詢條件可根據需求自定義。更多進階參數請參考官方的「批量匯入資源 (Import resources in bulk)」文件。

定義好查詢條件後，即可執行以下指令：

$ terraform query
Running query in HCP Terraform. Output will stream here. Pressing Ctrl-C
will stop streaming the logs, but will not stop the query running remotely.
 
Preparing the remote query run...
 
To view this query run in a browser, visit:
https://app.terraform.io/app/acfaria-hashicorp/ec2-search/search/qry-ubTgayE2hnLsF3LL
 
Waiting for the query run to start...
 
Terraform 1.14
on linux_amd64
Initializing plugins and modules...
list.aws_instance.unmanaged   account_id=008971679752,id=i-011f5cd5c03cc2560,region=us-east-2   unmanaged-instance-6
list.aws_instance.unmanaged   account_id=008971679752,id=i-0ca0957c269603542,region=us-east-2   unmanaged-instance-2
list.aws_instance.unmanaged   account_id=008971679752,id=i-0553ba06da0a4ae8f,region=us-east-2   unmanaged-instance-4
list.aws_instance.unmanaged   account_id=008971679752,id=i-0f10ea0f0d579ed3d,region=us-east-2   unmanaged-instance-3
list.aws_instance.unmanaged   account_id=008971679752,id=i-0ebdff0b154a659df,region=us-east-2   unmanaged-instance-1
list.aws_instance.unmanaged   account_id=008971679752,id=i-02c648ca8076d113f,region=us-east-2   unmanaged-instance-5

Terraform 搜尋結果會同步顯示在 CLI 介面與 HCP Terraform 控制台：

HCP Terraform 控制台呈現的搜尋查詢與結果畫面

HCP Terraform 控制台會同步顯示查詢設定，可以檢視各項未受控資源的細節，勾選欲匯入狀態檔（State）項目、點擊 「Generate Starter Configuration」 來生成初始代碼。

已勾選欲匯入的未受控資源

HCP Terraform 控制台自動產出匯入所需的 import 與 resource 區塊（如下圖）。請確認生成的 HCL 代碼無誤後，即可將未受控資源匯入 Terraform 狀態檔（State）。

HCP Terraform 控制台生成的初始代碼（Starter Configuration）

將產出的初始代碼複製到工作區的 main.tf 並視需求調整（如：移除衝突參數、修改標籤值），即可執行 terraform apply 將未受控資源匯入狀態檔（State）。

提示： 針對架構較複雜（complex schemas）的資源，Terraform 生成的預設代碼可能不完全正確，匯入前須手動微調。詳細資訊請參考官方文件的「限制說明（Limitations）」章節。

$ terraform apply
Running apply in HCP Terraform. Output will stream here. Pressing Ctrl-C
will cancel the remote apply if it's still pending. If the apply started it
will stop streaming the logs, but will not stop the apply running remotely.
 
Preparing the remote apply...
 
To view this run in a browser, visit:
https://app.terraform.io/app/acfaria-hashicorp/ec2-search/runs/run-ULkrfr9NQNNEjgAw
 
Waiting for the plan to start...
 
Terraform 1.14
on linux_amd64
Initializing plugins and modules...
aws_instance.unmanaged_4: Refreshing state... [id=i-0ebdff0b154a659df]
aws_instance.unmanaged_5: Refreshing state... [id=i-02c648ca8076d113f]
aws_instance.unmanaged_2: Refreshing state... [id=i-0553ba06da0a4ae8f]
aws_instance.unmanaged_3: Refreshing state... [id=i-0f10ea0f0d579ed3d]
aws_instance.unmanaged_1: Refreshing state... [id=i-0ca0957c269603542]
aws_instance.unmanaged_0: Refreshing state... [id=i-011f5cd5c03cc2560]
 
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place
 
Terraform will perform the following actions:
 
  # aws_instance.unmanaged_0 will be updated in-place
  # (will be imported first)
 …
 
Plan: 6 to import, 0 to add, 6 to change, 0 to destroy.

資源會立即匯入 CLI 與 HCP Terraform 狀態中。

aws_instance.unmanaged_5: Modifying... [id=i-02c648ca8076d113f]
aws_instance.unmanaged_1: Modifying... [id=i-0ca0957c269603542]
aws_instance.unmanaged_0: Modifying... [id=i-011f5cd5c03cc2560]
aws_instance.unmanaged_4: Modifying... [id=i-0ebdff0b154a659df]
aws_instance.unmanaged_3: Modifying... [id=i-0f10ea0f0d579ed3d]
aws_instance.unmanaged_2: Modifying... [id=i-0553ba06da0a4ae8f]
aws_instance.unmanaged_0: Modifications complete after 1s [id=i-011f5cd5c03cc2560]
aws_instance.unmanaged_1: Modifications complete after 1s [id=i-0ca0957c269603542]
aws_instance.unmanaged_2: Modifications complete after 1s [id=i-0553ba06da0a4ae8f]
aws_instance.unmanaged_5: Modifications complete after 1s [id=i-02c648ca8076d113f]
aws_instance.unmanaged_3: Modifications complete after 1s [id=i-0f10ea0f0d579ed3d]
aws_instance.unmanaged_4: Modifications complete after 1s [id=i-0ebdff0b154a659df]
 
 
Apply complete! Resources: 6 imported, 0 added, 6 changed, 0 destroyed.

並同步顯示於 HCP Terraform 控制台。

你可以在 AWS 控制台確認變更是否生效（例如 ManagedBy 標籤已更新為 terraform，且實例名稱變更為 managed-instance-#）。

AWS 控制台呈現匯入資源後的變更結果

使用 Terraform MCP Server 生成搜尋設定

談到 Terraform Search，另一個值得關注的應用是利用 Terraform MCP Server。它能協助開發者根據組織需求，撰寫更精確且相關的 Terraform 設定。

隨著最新版本發布，使用者只需在支援 MCP 的生成式 AI 工具中輸入指令，即可自動生成搜尋設定，例如：「請幫我搜尋標籤為 unmanaged 的未受控 aws_instance 資源，並使用組織 HCP Terraform 私有註冊表（Private Registry）中的 X 模組來進行匯入管理。」

這不僅把散落在外的資源抓回來，還能確保匯入的資源直接套用公司核可的架構範本，維持架構的一致性。

溫馨提醒：清理環境
使用測試資源進行實作，結束後記得執行 terraform destroy 徹底清理環境，以免產生不必要的帳單費用。

總結

面對規模化且碎片化的雲端環境，手動追蹤資源不僅累人，更是資安與合規的破口。透過 Terraform Search，終於能將散落在外的「管理斷層」轉化為自動化工作流，一鍵納管所有資產。

目前首波僅支援 AWS 部分資源（後續將陸續開放更多 Provider），這是邁向全環境自動化治理的關鍵一步。現在就動手清理你的雲端環境，重拾資源主控權吧！

本文翻譯自：Terraform search and import: Find resources and bring them into Terraform

想瞭解更多？歡迎聯絡我們，或是 加入歐立威 Line 好友！

每間公司有自己對 Devops 的定義與理解，不變的精髓是盡可能減少交付 (shipping)、快速迭代 ( iterating) 和確保軟體及應用程式的安全性 (securing)。

HashiCorp 將 DevOps 定義為一個組織流程，它必須結合現代應用程式的需求，賦權每個人員來提高敏捷性。

轉往雲端的營運團隊的挑戰：接納不同雲端供應商的異質性的同時，還要透過基礎設施即代碼來實現自動化

DevOps 涉及負責交付應用程式的主要人員，包括開發人員、營運人員和安全專家，這三個相互依存的角色需要緊密耦合的工具來協調對應用程式交付的投入。

DevOps 是一種從瀑布式軟體開發中跳脫出來的概念，在瀑布開發中，軟體應用程式是通過不同小組以線性、分步的方式交付的。開發人員接收需求並編寫應用程式，然後交給品質保證工程師 (QA) 進行測試。在開發階段之後，應用程式被交給發布團隊進行打包和用戶接受測試。測試完成後，安全專家會進入以確保合規性和最佳實踐。最終，操作人員部署應用程式，而瀑布的最後階段落在監控團隊上。

傳統的瀑布式軟體交付的問題在於，它優先考慮風險的最小化，而不是敏捷性的最大化。瀑布開發限制了個人自主權，減緩了回饋循環，並且每個小小的應用程式修改都需要許多團隊投入和檢查點。

DevOps 就是讓參與開發流程的各方人馬—營運、安全、開發—可以並行作業。HashiCorp 將應用程式交付流程的關鍵階段拆解，為每個參與者和任務提供最合適的工具，因此我們奉行優先考慮敏捷性、價值交付時間和迅速迭代的軟體更新流程。

DevOps 的興起也與混合雲基礎架構的崛起有關，混合雲基礎架構由分布式服務和數據中心組成。現代應用程式都是連網的精簡型用戶端 (thin clients) ，例如瀏覽器和行動應用程式，因此更新可以快速交付，通常也不需要嚴格的風險管理的「召回 (recall)」。

一致的開發方法得以容納應用程式的異質性

DevOps 落實得當的話可以最大化軟體交付的速度。透過全局性地看待整個交付過程，我們可以消除傳統開發流程上某個角色可能會超載的瓶頸；畢竟，水桶能裝多少水是由最短的木板決定的，軟體的交付速度也是取決於最慢的開發小組。

軟體交付的 7 個階段

每個組織的軟體交付流程都有略微不同的要素，這些要素會受到技術選擇、合規要求或其他因素的影響，但大致上軟體交付週期有 7 個階段：

1. 建置 (Build)

應用程式始於開發人員編寫程式碼，新的應用程式就必須編寫初始版本；但對於已經存在的應用程式，開發週期似乎永無止境 – 新增新功能、提高可用性、修正錯誤、改善效能…等。建置階段主要由開發人員負責，但營運團隊可能需要負責提供開發人員用於編寫程式碼的環境和工具。

2. 測試 (Test)

在應用程式被編寫和發佈之前，它會經歷多種測試。最簡單的測試，即單元測試，由開發人員完成，並且可以與整合測試、驗收測試、端到端測試等進行分層。這是應用程式交付週期中的重要環節，因為它提供了自動化回饋和重要的風險管理控制。這個階段主要由開發人員負責，但也包括專門的品質保證團隊和營運團隊，他們可能負責測試用的環境。

3. 打包 (Package)

打包：一旦應用程式被編寫和測試，就需要將其打包以投入正式使用。基礎應用程式會從原始碼形式打包成可執行的文件。打包階段可能會重度依賴技術或正式上線的環境。例如，JBoss 的 WAR 文件或 Kubernetes 的 Docker 容器。在某些情況下，這些打包檔可能會儲存在 Artifactory 或 Sonatype Nexus 等工件儲存庫中。

4. 配置 (Provision)

應用程式需要有地方運行，在所有抽象層之下，仍然需要提供計算、儲存和網路資源。這些資源可以直接以實體機或虛擬機 (VM) 提供，也可以間接地通過基礎設施即服務 (IaaS) 提供。在任何情況下，這些資源都需要按照應用程式規格進行準備和配置，並在使用壽命結束時進行更新和最後的停用。配置階段通常由營運團隊負責，並作為一項服務提供給開發人員。

5. 安全性 (Secure)

系統的整體安全性取決於最弱的那塊，這意味著安全性應該從應用程式交付流程的一開始就被納入考慮。安全團隊在開發期間確保使用最佳實踐，協助建模網路拓撲，保護用於部署基礎設施的憑證，並授予部署應用程式所需的密碼，例如資料庫密碼和 API 令牌。安全性通常由專職的角色負責，但也包括所有其他參與應用程式交付的團隊。

6. 部署 (Deploy)

在基礎資源配置好之後，部署階段就是將打包好的應用程式運行起來。如果機器或 VM 被專門用來運行單個應用程式，那麼配置階段就會與部署階段緊密耦合；如果使用調度器 (scheduler) 動態地將應用程式部署到機器上，那麼配置階段就會與部署階段解耦。

7. 監控 (Monitor)

運行中的應用程式需要被監控，以確保它們持續以健康的性能運行。服務需要相互聯繫，同時避免與故障或性能不佳的實例通訊，這也導致服務發現的必要性。監控階段涵蓋了從粗粒度的服務生存狀態測量到詳細的日誌記錄和遙測等，監控階段涉及的人員包含想要了解應用程式行為的開發人員、管理基礎設施的營運人員以及維護整體應用程式的監控人員和 SRE (site reliability engineers)。

DevOps 交付，為任何應用程式配置、防護和運行於任何基礎架構

設計高效能的組織就像設計高效能應用程式一樣：應該要盡可能減少協商 ( coordination)，不論是組織或是應用程式都遵循 Amdahl 定律，如果我們將每個人都視為「執行單位」，那麼整體的生產力也會被協商程度限制。

上述交付應用程式的七個階段是不能跳過的，因此重點是如何最大程度地減少每個階段所需的協商程度。如果每個團隊都被授權獨立工作，就可以減少協商並提高每個人的生產力，應用程式交付速度也會因此提升。

這是 DevOps 的核心理念，我們選擇的工具必須優先考慮這些關鍵功能。為了維持一致的開發流程，這些工具必須專注於工作流程，而不是技術，以解決大多數組織面臨的技術異質性。

HashiCorp 提供一套以 DevOps 為中心的工具，專注於減少應用程式交付週期各個階段的人工協商。

HashiCorp Vagrant

Vagrant 允許開發人員自己快速建立開發環境，而無需諮詢同事或營運人員。它還提供了一個類似正式環境的環境，使開發人員可以輕鬆更快地取得代碼測試回饋，這也是持續整合 (CI) 的目標之一，因為它允許開發人員藉由更快地提供回饋來提高個人生產力。(更多原廠介紹)

HashiCorp Packer

Packer 為任何目標環境提供單一工作流程來打包應用程式。透過共享配置，Packer 允許團隊解耦並降低協商。協調被推到工件儲存庫中，例如 Artifactory 或 Docker Hub，因此開發人員無需擔心部署的細節。(更多原廠介紹)

HashiCorp Terraform

Terraform 是一種使用通用工作流程，在任何基礎架構中提供基礎架構和應用程式資源的產品。Terraform 使操作員能夠安全、可預測地創建、更改和改進正式環境的基礎架構。它將 API 編碼為可在團隊成員之間共享、被視為代碼、編輯、審查和版本化的宣告性配置文件 (declarative configuration files)。(Terraform 中文介紹)

HashiCorp Vault

Vault 在應用程式交付週期的每個階段提供集中式密鑰管理方法。它使用高度可用和安全的方法儲存和揭露密鑰給應用程式和最終用戶。Vault 允許團隊直接取得需要的數據，而不用等待安全團隊的批准。安全團隊可以更改密碼、輪換憑證和更新安全策略，免去在組織內部協商的流程。( Vault 中文介紹)

HashiCorp Nomad

Nomad 是集群管理器和調度器。調度器允許組織將關注的項目進一步解耦，並完全將機器抽象化給開發人員。取而代之的是，開發人員專注於他們想要運行的應用程式，並允許調度程序將應用程式放置在基礎架構上並管理機器的容量。Nomad 允許操作員提供機器群，與提交作業給 Nomad 的開發人員解耦。Nomad 將應用程式放置在可用機器上，操作員和開發人員免去協商與手動調整。(更多原廠介紹)

HashiCorp Consul

Consul 是 HashiCorp 的服務發現和監控工具，它也是服務網格的數據平台組件。Consul 允許運行的應用程式廣播其可用性並與其他應用程式通信。例如，Web 服務器可以使用 Consul 找到其上游資料庫或 API 服務。Consul 還監控應用程式的健康狀況，以確保只有健康的實例接收流量，並通知開發人員或操作員問題。這允許開發團隊避免在 IP 位址上協商，並在應用程式的運行時推入服務發現，因此服務可以獨立更新。通過由各個團隊並行更新獨立服務，提高了生產力，而不用像單一代碼庫所需的那種協作方式，Consul 解決了微服務和面向服務的架構相關的許多挑戰。(更多原廠介紹)

做對 DevOps ，讓營運、安全和開發團隊並行工作

隨著每個公司都成為軟體公司，執行 DevOps 的能力使他們能夠更快地交付更好的應用程式，全球數十萬專業軟體人員都使用 HashiCorp DevOps 套件來實現這一點。

透過專為 DevOps 的每個階段設計的工具，HashiCorp 讓軟體開發流程的不同參與者（開發、營運和安全團隊）專注於他們的主要任務，解除他們並行工作的阻礙，這意味著將瀑布式開發流程轉變為三個團隊可以並行運行的開發流程。

本文翻譯自原廠文章：DevOps Defined – Accelerating the Application Delivery Lifecycle