荷蘭銀行實施大規模DevOps經驗

集中組織和基於產品
10 多年前，在合併期間，我被要求檢視組織的支援和開發工具。ABN AMRO 那時仍然是一個以專案為導向的組織，其中 Dev 和 Ops 組是分開的。根據以往的經驗，我們已經很清楚，主要的工具，包括版本控制、原始碼質量控制、管道支援和工件管理，都應該集中管理。這主要是為了滿足非開發人員的要求，例如可追溯性和集中報告的能力。至少應遵守最低限度的統一性。另一個重要的選擇是產品定位。過去在又一次重組後面臨孤立的原始碼儲存庫，我很清楚按照組織結構組織開發資料並不是一個好的選擇。由於正在開發的東西的生命週期通常比開發者長得多，因此選擇了基於產品的方法。
快進到今天，該組織正在（正在）轉變為 DevOps 結構，大約有 400 個開發團隊負責開發和運營。10 年前只有少數人的工具支援已經發展成為開發服務，有 200 多人支援更多。這些包括：

1. 軟體開發標準和指南
2. 所有與開發相關的工具
3. 內部和外部開發人員門戶
4. 基於設計模式的程式碼初始化
5. 管道的標準構建塊和常用技術的模板管道
6. CI/CD 輔導
7. 為許多供應商特定平臺提供託管服務並支援技術行會
8. 作為開發工具的一部分，從一開始就使用了 Landscape Nexus Repository Manager <link>，隨後是 Nexus Lifecycle。

IT4IT 資料模型
缺少原始碼、開發資料、CI/CD 資料和服務管理資料之間的結構關係，隨著我們以產品為導向，管理人員圍繞開發資料發展，顯示使用哪些工具開發了哪些應用程式。這包括 Bitbucket、Jenkins、SonarQube、Fortify、Nexus Lifecycle 和 Nexus Repository Manager。在服務管理方面，開發了一個應用程式組合來支援常規服務管理流程以及監管和企業架構流程。
我還目睹了一種反覆出現的模式，即主要的生命週期管理和基礎設施專案查詢應用程式的詳細資訊。時不時地，開發組織不得不將技術細節收集到大型 Excel 表格中，以滿足那些重大專案或計劃的資料需求。在專案結束時，資訊丟失了，在下一個專案中重複了這個練習。我們的應用工程資料根本無法以結構化的形式提供，開發團隊以外的利益相關者也無法訪問。
與此同時，市場上出現了IT4IT倡議。這個概念強化了整個 IT 價值鏈中的資料應該被更好地定義以支援任何規模化方法的想法，無論是大規模敏捷、大規模 DevOps 還是大規模數字化轉型。敏捷和 DevOps 轉型中的一個風險是管理層無法瞭解正在發生的事情。
  

工具入職
 CI/CD 環境最初包括 Bitbucket、Jenkins、SonarQube、Nexus Repository Manager，最重要的是我們管理所有相關訪問組的中央 LDAP。需要技術問題來初始化對 Nexus 儲存庫管理器中儲存庫內的適當儲存庫和路徑的訪問。
隨著 Fortify 和 Nexus Lifecycle 的引入，很明顯需要在另一個級別上進行引導。雖然我們的應用程式組合假設應用程式是一個完整的解決方案，包括所有軟體和基礎設施，但 Fortify 和 Nexus Lifecycle 等工具則著眼於軟體/可部署單元。我們做出了一些與命名約定相關的半心半意的決定，這些約定將載入的專案與總體應用程式聯絡起來。將 SonarQube 加入相同的可部署單元是在管道中自動完成的。如果向 SonarQube 提供帶有未知識別符號的掃描結果，它會動態地在資料庫中建立一個新條目。
應管理層的要求，我們部門的另一個團隊針對一些 CI/CD/DevOps 指標和程式碼質量建立了儀表板。為此，建立了另一個管理來連結團隊、應用程式和軟體元件。此應用程式關聯並收集了來自 SonarQube、Fortify 和 Nexus Lifecycle 的資料。
  

連線點
IT 的主要目的是實現公司的業務目標，但圍繞 IT4IT 的一些概念側重於 IT 的需求。在這個過程中有一些巨大的改進，以及相關的業務目標。
大多數開發工具起源於單個團隊-單個專案的情況，企業支援大多是事後才加入的。從數字產品的角度來看，與單個產品或產品中的單個元件相關聯的工程資料分散在許多面向功能的工程工具中。沒有明確標識數字產品或數字元件的中央管理機構。它也不會以一致且技術中立的方式交叉引用工具中的相關工程資料。在設計時也沒有對數字產品組合的結構化洞察。我們也缺乏對操作配置項與其來源的工程資料之間的關係的理解。
開發團隊的自助服務設施不應僅限於入職，而必須涵蓋數字產品及其元件的整個生命週期。這些設施應提供完全直通式處理，以避免開發團隊和支援工具的團隊之間出現任何不必要的依賴關係。
從價值鏈/供應鏈的角度來看，瞭解我們為客戶提供的數字產品的構成更為重要。一個 DevOps 團隊可以完全負責其產品的所有方面，這是一種錯覺。從敏捷的角度來看，完全獨立是理想的，但在企業層面呢？它根本無法擴充套件。而且，就人力資源而言，這將是非常昂貴的。
瞭解產品組成以及上游和下游依賴關係對於大規模實施敏捷或 DevOps 至關重要。
 

理論上的解決方案
鑑於具有所有權的概念級別（產品組合）和工程級別（DCI），包括組合關係，團隊之間出現了生產者-消費者關係。
DCI 按型別分類，對於每種型別，都標識了必需的資料元素（這意味著必需的工具）。然後，確定這些元素的內部關係。例如，根識別符號與派生識別符號。
例如，基本識別符號為組 ID、工件 ID 和版本 (GAV) 的 Java 元件在 POM.XML 檔案中定義。在這種情況下，對於 ABN AMRO 建立的元件，其他命名約定適用。必須使用 SonarQube、Fortify、Nexus Lifecycle 和 Nexus Repository Manager。這些工具中關聯物件的識別符號來自 GAV。例如，SonarQube::Project、Fortify::Application、NexusLifecycle::Application、NexusRepositoryManager::Artifact 的識別符號。
 

目前的解決方案
首先，我們將自己限制在一種產品、應用程式和一小組 DCI：僅應用程式和軟體元件。我們現在也忽略了多個版本。
在產品組合級別，所有應用程式都已經在概念級別 (S2P) 註冊，封裝了應用程式的整個生命週期。在工程層面（R2D），大致做了以下工作：

1. 對於現有應用程式，會建立相應的 DCI。
2. 提供以下直接處理應用程式載入服務：為名為<application acronym>的新應用程式建立 CI/CD 環境
3. 對於新的自主軟體元件，提供以下服務：將 元件<元件列表>新增到應用程式<應用程式首字母縮略詞>

• 在 LDAP 中建立特定於應用程式的訪問組
• 在適當的 Nexus Repository 儲存庫中建立特定於應用程式的訪問路徑
• 在 SonarQube 中建立應用程式級訪問

• 是識別符號
• 使用者需要的其他輸入
• 哪些工具已載入
• 入駐狀態

技術實現
解決方案的架構應支援 ABN AMRO 使用的所有 CI/CD 工具。所有 CI/CD 工具都由多個團隊在一個部門管理，每個團隊負責多個工具。因此，該架構有兩個不同的層：一箇中央服務，它公開一個供客戶端程式使用的 API。
對於每個工具，都有一個特定的服務將中央服務期望的 API 轉換為特定於工具的 API 呼叫。每項工具服務都將我們的 IT4IT 運營模型（如我們的服務管理中所表示的）轉化為特定於工具的概念，反之亦然。例如，我們要求到SonarQube服務和Nexus倉庫管理器服務並重：ç reate一個新的應用程式CI / CD環境 與給定的名稱。對於 SonarQube 和 Nexus Repository Manager，這個請求意味著不同的東西。對於 SonarQube，基於這一請求進行了 16 次 API 呼叫。
目前，我們已經在我們的內部網上為上述兩項服務實施了一個客戶端流程和兩個請求表。表單根據團隊成員資格和應用程式所有權過濾選項列表，如服務管理中所知。從技術角度來看，每項服務都實現為一個容器，並部署在同一個 k8s（Kubernetes）叢集上。
三個團隊現在參與提供這些服務，這些服務涵蓋了 ABN AMRO CI/CD 工具的大部分。