圖片：
大家好！ 我們是公司的自動化工程師 我們支持公司產品的開發：我們支持從開發人員提交一行代碼到在更新服務器上發布成品和許可證的整個組裝管道。 非正式地，我們被稱為 DevOps 工程師。 在本文中，我們想討論軟件生產過程的技術階段、我們如何看待它們以及如何對它們進行分類。
從材料中，您將了解協調多產品開發的複雜性、技術地圖是什麼以及它如何幫助簡化和復制解決方案、開發過程的主要階段和步驟是什麼、我們公司的 DevOps 和團隊之間的職責範圍如何。
關於混沌和 DevOps
簡而言之，DevOps 的概念包括開發工具和服務，以及它們的使用方法和最佳實踐。 我們來挑出全球的 目標 從我們公司實施 DevOps 理念來看：這是在數量上（工時或機器時數、CPU、RAM、磁盤等）產品生產和維護成本的持續降低。 在整個公司層面降低總體開發成本的最簡單、最明顯的方法是 最大限度地減少執行典型串行任務的成本 在生產的各個階段。 但這些階段是什麼，如何將它們與一般過程分開，它們由哪些步驟組成？
當一家公司開發一種產品時，一切都或多或少是清楚的：通常有一個共同的路線圖和開發方案。 但當產品線擴大、產品多了怎麼辦？ 乍一看，他們有相似的流程和流水線，日誌和腳本中的“找X差異”遊戲開始了。 但是，如果已經有 5 個以上的項目正在積極開發並且需要支持數年開發的多個版本怎麼辦？ 我們是否想要在產品管道中重複使用盡可能多的解決方案，或者我們準備好花錢為每個解決方案進行獨特的開發嗎？
如何在獨特性和系列化解決方案之間找到平衡？
自2015年以來，這些問題開始越來越頻繁地出現在我們面前。 產品數量不斷增長，我們試圖將支持這些產品裝配線的自動化部門 (DevOps) 擴大到最低限度。 同時，我們希望在產品之間複製盡可能多的解決方案。 畢竟，為什麼十種產品以不同的方式做同樣的事情呢？
開發總監：“伙計們，我們能以某種方式評估 DevOps 對產品的作用嗎？”
我們：“我們不知道，我們沒有問這樣的問題，但是應該考慮哪些指標？”
開發總監： “誰知道！ 思考…”
就像在那部著名電影中一樣：“我在一家酒店！......” - “呃......你能給我帶路嗎？” 經過反思，我們得出的結論是，首先要確定產品的最終狀態； 這成為我們的首要目標。
那麼，如何在 10 到 200 人的相當大的團隊中分析十幾種產品，並在復制解決方案時確定可衡量的指標？
1:0 支持 Chaos，或者肩胛骨上的 DevOps
我們首先嘗試應用 IDEF0 圖和 BPwin 系列的各種業務流程圖。 混亂是在下一個項目下一階段的第五個方格之後開始的，每個項目的這些方格都可以在 50+ 步驟下畫在一條長蟒蛇的尾巴上。 我感到悲傷，想對著月亮嚎叫——它不適合一般情況。
典型生產任務
生產流程建模是一項非常複雜且艱鉅的工作：您需要收集、處理和分析來自各個部門和生產鏈的大量數據。 您可以在文章中閱讀更多相關內容““。
當我們開始對生產流程進行建模時，我們有一個特定的目標 - 向參與公司產品開發的每位員工以及項目經理傳達：
- 產品及其組件如何從提交一行代碼開始以安裝程序和更新的形式到達客戶，
- 為產品生產的每個階段提供了哪些資源，
- 每個階段涉及哪些服務，
- 每個階段的責任範圍如何劃分，
- 每個階段的入口和出口存在哪些合約。
單擊圖像將以全尺寸打開。
我們在公司的工作分為幾個職能領域。 基礎設施的方向致力於部門所有“鐵”資源運行的優化，以及虛擬機及其上環境部署的自動化。 監控方向提供24/7的服務性能控制； 我們還為開發人員提供監控即服務。 工作流方向為團隊提供了管理開發和測試流程、分析代碼狀態以及獲取項目分析的工具。 最後，webdev 方向提供在 GUS 和 FLUS 更新服務器上發布版本，以及使用 LicenseLab 服務的產品許可。 為了支持生產流程，我們為開發人員建立並維護了許多不同的支持服務（您可以在舊聚會上聆聽其中一些故事： и）。 我們還開發內部自動化工具，包括 .
五年來，我們的工作積累了很多同類型、常規的操作，我們其他部門的開發人員主要來自於所謂的 典型任務其解決方案是完全或部分自動化的，不會給表演者帶來困難，也不需要大量的工作。 我們與主要領域一起分析了這些任務，並能夠確定各個工作類別，或者 生產步驟，各個階段被分成不可分割的步驟，幾個階段相加 生產流程鏈.
技術鏈最簡單的例子是公司內每種產品的組裝、部署和測試階段。 例如，構建階段又包含許多單獨的典型步驟：從 GitLab 下載源代碼、準備依賴項和第 3 方庫、單元測試和靜態代碼分析、在 GitLab CI 上執行構建腳本、在 Artifactory 存儲庫中發布工件以及通過我們的內部 ChangelogBuilder 工俱生成發行說明。
您可以在我們關於 Habré 的其他文章中閱讀有關典型 DevOps 任務的信息：““和”“。
形成許多典型的生產鏈 製造工藝。 描述流程的標準方法是使用功能性 IDEF0 模型。
製造 CI 流程建模的示例
我們特別關注持續集成系統標準項目的開發。 這使得實現項目的統一成為可能，突出了所謂的 發布構建方案並進行促銷.
這是它的工作原理。 所有項目看起來都很典型：它們包括屬於 Artifactory 快照存儲庫的程序集配置，之後在測試台上進行部署和測試，然後提升到發布存儲庫。 Artifactory 服務是團隊和其他服務之間所有構建工件的單一分發點。
如果我們極大地簡化和概括我們的發布方案，那麼它包括以下步驟：
- 跨平台產品組裝，
- 部署到測試台，
- 運行功能和其他測試，
- 推廣經過測試的版本以在 Artifactory 上發布存儲庫，
- 版本的發佈建立在更新服務器上，
- 交付組件和生產更新，
- 啟動產品的安裝和更新。
例如，考慮功能IDEF0模型形式的這種典型發布方案的技術模型（下文簡稱模型）。 它反映了我們 CI 流程的主要階段。 IDEF0 模型使用所謂的 國際博物館協會符號 （輸入-控制-輸出-機制）描述每個階段使用什麼資源，基於什麼規則和要求執行工作，輸出是什麼，以及特定階段實施什麼機制、服務或人員。
單擊圖像將以全尺寸打開。
通常，在功能模型中分解和詳細描述流程更容易。 但隨著元素數量的增加，理解其中的某些內容變得越來越困難。 但在實際開發中，還有輔助階段：監控、產品認證、工作流程自動化等。 正是由於縮放問題，我們放棄了這種描述。
希望的誕生
在一本書中，我們看到了描述技術流程的蘇聯舊地圖（順便說一句，這些地圖至今仍在許多國有企業和大學使用）。 等等，等等，因為我們也有工作流程！...有階段、結果、指標、需求、指標等等...為什麼不嘗試將流程圖也應用到我們的產品管道中呢？ 有一種感覺：“就是這個了！ 我們已經找到了正確的線索，是時候把它拉好了！
在一個簡單的表格中，我們決定按列記錄產品，按行記錄技術階段和產品管道。 里程碑是一些大的事情，例如產品構建步驟。 步驟更小、更詳細，例如將源代碼下載到構建服務器的步驟或編譯代碼的步驟。
在地圖行和列的交叉點，我們記錄了特定階段和產品的狀態。 對於狀態，定義了一組狀態：
- 沒有信息 - 或不合適。 需要分析產品中某個階段的需求。 要么已經進行了分析，但目前不需要該階段，或者在經濟上不合理。
- 推遲 - 或目前不相關。 需要一個階段的準備，但今年沒有實施的力量。
- 計劃。 該階段計劃於今年實施。
- 實施的。 管道中的階段按所需數量實施。
表格的填寫開始逐個項目進行。 首先，對一個項目的階段和步驟進行分類並記錄其狀態。 然後他們開始了下一個項目，修復了其中的狀態，並添加了先前項目中缺少的階段和步驟。 由此，我們獲得了整個生產流程的階段和步驟以及它們在特定項目中的狀態。 結果與產品管道能力矩陣類似。 我們將這樣的矩陣稱為技術地圖。
借助技術地圖，我們與團隊合理協調今年的工作計劃以及我們要共同實現的目標：今年項目增加哪些階段，哪些階段留到以後。 此外，在工作過程中，我們可能會對僅針對一種產品完成的階段進行改進。 然後我們擴展我們的地圖並將此改進作為一個階段或新步驟引入，然後我們對每個產品進行分析並找出複制改進的可行性。
他們可能會反對我們：“這當然很好，只是隨著時間的推移，步驟和階段的數量會變得令人望而卻步。 怎樣成為？
我們對每個階段、每個步驟的要求都做了規範、比較完整的描述，讓公司內部的每個人都能以同樣的方式理解。 隨著時間的推移，隨著改進的引入，一個步驟可能會被另一個階段或步驟吸收，然後它們就會“崩潰”。 同時，所有要求和技術細微差別都符合概括階段或步驟的要求。
如何評估複製方案的效果？ 我們使用一種極其簡單的方法：將實施新階段的初始資本成本歸因於年度一般產品成本，然後在復制時除以全部。
部分開發項目已在地圖上顯示為里程碑和步驟。 我們可以通過在典型階段引入自動化來降低產品成本。 之後，我們考慮定性特徵、定量指標和團隊獲得的利潤（以節省的工時或機器工時為單位）的變化。
生產工藝流程技術圖
如果我們將所有階段和步驟都用標籤進行編碼並將它們展開為一條鏈，那麼它將變得非常長且難以理解（正是我們在文章開頭談到的“python 尾巴”）：
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]這些階段包括構建產品 [Build]、將其部署到測試服務器 [Deploy]、測試 [Test]、根據測試 [Promote] 的結果將構建提升到發布存儲庫、生成和發布許可證 [License]、在 GUS 更新服務器上發布 [Publish] 並將其交付到 FLUS 更新服務器、使用產品配置管理 [Install] 在客戶基礎設施上安裝和更新產品組件，以及從已安裝的產品收集遙測數據 [Telemetry]。
除此之外，還可以區分不同的階段：基礎設施狀態監控[InfMonitoring]、源代碼版本控制[SourceCodeControl]、構建環境準備[Prepare]、項目管理[Workflow]、為團隊提供通信工具[Communication]、產品認證[Certification]以及確保CI流程的自給自足[CISelfSufficiency]（例如，程序集獨立於互聯網）。 我們的流程中的數十個步驟甚至不會被考慮，因為它們非常具體。
如果以形式呈現的話，會更容易理解和查看整個生產流程 技術地圖; 這是一個表格，其中模型的各個生產階段和分解步驟以行形式寫入，並以列形式描述每個階段或步驟所做的事情。 主要重點放在每個階段提供的資源以及責任範圍的劃分。
對我們來說，地圖是一種分類器。 它反映了產品生產的大量技術部分。 有了它，我們的自動化團隊可以更輕鬆地與開發人員互動，共同規劃自動化階段的實施，並了解為此需要哪些勞動力成本和資源（人力和硬件）。
在我們公司內部，地圖是從 jinja 模板自動生成為常規 HTML 文件，然後上傳到 GitLab Pages 服務器。 可以查看包含完整生成的地圖示例的屏幕截圖 .
單擊圖像將以全尺寸打開。
簡而言之，工藝圖是生產過程的概括圖，它反映了具有典型功能的清晰分類的塊。
我們路線圖的結構
該地圖由幾個部分組成：
- 標題區——這裡是地圖的總體描述，介紹基本概念，定義主要資源和製作過程的結果。
- 儀表板 - 在這裡您可以控制單個產品的數據顯示，提供所有產品的總體實施階段和步驟的摘要。
- 技術地圖 - 技術流程的表格描述。 在地圖上：
- 給出了所有階段、步驟及其代碼；
- 給出了各個階段的簡短而完整的描述；
- 指出每個階段使用的投入資源和服務；
- 指示每個階段和單獨步驟的結果；
- 標明每個階段和步驟的責任範圍；
- 已經確定了支持現階段工作所需的技術資源，例如 HDD (SSD)、RAM、vCPU 以及所需的工時，無論是當前（事實）還是未來（計劃）；
- 對於每種產品，都標明了已實施、計劃實施、不相關或未實施的技術階段或步驟。
基於技術地圖的決策
檢查完地圖後，可以根據員工在公司中的角色（開發經理、產品經理、開發人員或測試人員）採取一些行動：
- 了解實際產品或項目中缺少哪些階段，並評估其實施的必要性；
- 劃分不同階段工作的多個部門之間的職責範圍；
- 商定舞台入口和出口的合同；
- 將您的工作階段融入到整體開發流程中；
- 更準確地評估提供每個階段的資源需求。
總結以上所有內容
該路由具有通用性、可擴展性和易於維護性。 與嚴格的學術 IDEF0 模型相比，以這種形式開發和維護流程描述要容易得多。 此外，表格描述比功能模型更簡單、更熟悉且結構更好。
對於這些步驟的技術實現，我們有一個特殊的內部工具CrossBuilder——CI系統、服務和基礎設施之間的層工具。 開發人員不需要砍掉他的自行車：在我們的 CI 系統中，運行 CrossBuilder 工具的腳本之一（所謂的任務）就足夠了，考慮到我們基礎設施的特性，它將正確執行它。
結果
這篇文章相當長，但在描述複雜過程的建模時這是不可避免的。 最後我想簡單說一下我們的主要想法：
- 在我們公司實施 DevOps 理念的目標是在數量上（工時或機器時、vCPU、RAM、磁盤）持續降低公司產品的生產和維護成本。
- 降低總體開發成本的方法是最小化執行典型串行任務的成本：技術過程的階段和步驟。
- 典型的任務是其解決方案完全或部分自動化、不會給執行者帶來困難並且不需要大量勞動力成本的任務。
- 生產過程由階段組成，階段又分為不可分割的步驟，是不同規模和範圍的典型任務。
- 從不同的典型任務中，我們得出了複雜的技術鍊和生產過程的多層次模型，這些模型可以通過功能性 IDEF0 模型或更簡單的技術圖來描述。
- 技術圖是生產過程的階段和步驟的表格表示。 最重要的是：地圖可以讓您完整地、大塊地看到整個過程，並可以詳細說明它們。
- 基於技術地圖，可以評估在特定產品中引入階段的需要，劃定責任範圍，就階段的輸入和輸出達成合同，並更準確地評估資源需求。
在接下來的文章中，我們將更詳細地描述使用哪些技術工具來實現我們地圖上的某些技術階段。
文章作者：
- — Positive Technologies 自動化 (DevOps) 主管
- - 副手Positive Technologies 自動化部門 (DevOps) 主管
來源： www.habr.com