天馬行空-DevOps平臺建設概述
概述
DevOps（Development和Operations的組合詞）是一組過程、方法與系統的統稱，用於促進開發（應用程式/軟體工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。它是一種重視“軟體開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟體交付”和“架構變更”的流程，來使得構建、測試、釋出軟體能夠更加地快捷、頻繁和可靠。
本篇主要概述的是Dev環節的支撐平臺。如何一套Dev平臺來同時支援傳統企業交付模式以及網際網路業務交付模式。關於支撐Ops階段的平臺涉及內容龐大複雜，後續從資料中心Ops的角度展開論述。
關於本人對Dev與Ops環節的支撐平臺的劃分，大致為如下：
場景分析
網際網路業務的特點是自開發，自運維，標準的devops模式，從研發活動來看，涉及五個階段，code，build，test，deploy，monitor。每個階段的職責不同。
傳統IT業務的特點是研發團隊負責開發交付，IT技術支援團隊負責實施（部署，升級），客戶負責運維。且傳統IT企業交付的往往是一整套完整的解決方案。
相比較網際網路業務模式，研發活動流程變為了如下，增加了assemble(裝配過程)。
也就是如何將開發團隊的輸出裝配為面向客戶交付的解決方案包。
兩種場景下的共同訴求都是devops理念中構建，測試，釋出更加快捷，頻繁，可靠。
Code階段
核心目標是如何快速，低門檻的開發，同時對於QA來說，如何可進行統計度量（程式碼量，產出率等）。而快速，低門檻則儘可能讓開發只聚焦與核心業務邏輯的實現，更多的工程相關的屬性依託於視覺化，自動化的構築生成。因此需要契約化的工程結構，以支撐後續的執行維護管理。微服務架構模式下，微服務是最小的工程單元，因此也即是定義一種符合微服務的契約化的工程屬性。微服務的特徵要求具備獨立可編譯部署變更，對外需要清晰的API等。
因此可以定義譬如下面的開發工程的目錄結構
一般一個微服務的開發順序可參照如下：
一般在設計階段就需要輸出API定義，傳統的往往是word或者excel等定義，用於評審，然後開發階段需要編寫程式碼去定義，此部分則可以完全簡化，基於YAML/JSON定義API檔案，並基於Swagger直接視覺化展示API用於評審，開發階段同樣基於此檔案直接生成API程式碼和到業務邏輯的呼叫。最終開發者直接編寫API的實現單元即可。
依託於契約化鬆耦合的目錄結構，需要devops平臺具備如下的能力：
1：微服務的初始化管理服務。微服務自身就是個後續需要被維護管理的物件，故而需要一個微服務管理的能力。包含：微服務定義，開發工程生成，以及關鍵指標的蒐集（程式碼量，開發語言，責任人，提交次數等）
2：基於主流開發工具（Eclipse，IDEA）可一鍵式生成API程式碼。
微服務初始化管理服務（後續簡稱codeinit）結構可大致表述為如下
至此基於微服務管理服務的code過程變為：
Build階段
核心目標是檢查原始程式碼的質量並編譯生成可執行的包。
- 下載程式碼：是指從程式碼倉庫下載到編譯伺服器
- 門禁檢查：包含契約化目錄規範的檢查，圈複雜度檢查，findbugs檢查，程式碼樣式檢查等。
- 編譯：則是將原始程式碼生成二進位制，使用語言自身的編譯器完成，打包則是生成預期的最終可部署的包，其包含編譯產生的二進位制檔案以及程式的配置檔案等。
- 推送：是指生成的包推送到包倉庫(FTP伺服器，映象庫等)。
- 統計：貫穿在整個Build階段，是指Build階段的各種度量指標，譬如編譯次數，編譯成功率等。
，
Assemble階段
Assemble核心目標是微服務包到服務包，服務包到解決方案大包，或者微服務包到解決方案大包的自動化裝配過程。
需要一種契約化的包的裝配規則的定義，包含目標包型別（解決方案，服務），包含的服務或者微服務。最終客戶拿到的是一個基於部署系統可部署的完整的大包，不用自己手動下載組裝配套的多個包。
最終效果：研發團隊視角提供微服務，形成一種原子能力的微服務池子，不同解決方案定義不同的微服務打包策略，基於devops平臺自動裝配不同的解決方案包。
Deploy階段
Deploy階段隸屬於Ops範圍，涉及上下文很多，後續詳細展開論述，此部分只做概要介紹。
部署系統的核心目標是視覺化/自動化的將解決方案包/服務包/微服務包部署到不同的環境的節點上。這裡面涉及幾個名詞：包，部署動作，環境，節點，需要展開論述。
包指的是開發活動交付的軟體的載體。可以是zip/映象等。
環境：指的是部署活動中涉及的Alpha（服務內自驗證環境），Beta(服務間聯調環境)，Gamma(類生產環境)，Gamma(生產環境)。
節點：這裡面定義的是在可直接部署包的介質，需要強調的是可直接部署性。一般性硬體和軟體是分離的兩撥人，一個數據中心內允許兩次駐場，以此是裝置採購到位後，硬體調測人員進駐進行硬體安裝配置，其次是軟體調測人員駐場，進行作業系統安裝及其之後的過程，而對於部署系統來說，此處部署的是軟體包，並不包括OS安裝配置，故而也就引出了另一個系統：獨立的裝機服務，此即為部署系統的其中一個上下文，但並非屬於部署系統。但是實際往往也可能沒有獨立的裝機服務，譬如節點如果全是虛擬機器，而一般企業往往虛擬機器的生命週期管理存在與獨立的雲管理平臺中（物理機的初始化，OS安裝，虛擬機發放）。此時雲管理平臺即可承載此處所需的裝機能力。
Monitor階段
DevOps模式下的Monitor隸屬於Ops範圍，涉及內容和上下文很多，其內容包含監控（硬體，OS，業務的效能，呼叫鏈，撥測），告警，故障診斷等，上下文涉及變更，事件，報表，通道等後續詳細展開論述。
此處需要附加說明的是即使從Dev階段也是需要Monitor能力的，也就是監控統計Code，Build，Assemble階段的各個指標