今天整理下從傳統(tǒng)的CI/CD到DevOps研發(fā)運(yùn)維一體化的整個(gè)演進(jìn)過程。類似于每日構(gòu)建和冒煙測(cè)試，實(shí)際上在10多年前就已經(jīng)在實(shí)踐，比如當(dāng)前用的筆記多的Ant+CruiseControl方式來實(shí)現(xiàn)自動(dòng)化的編譯構(gòu)建和持續(xù)集成能力。

包括當(dāng)前DevOps過程實(shí)踐中的持續(xù)集成，實(shí)際和原來在思想上并沒有太大的變化，對(duì)于DevOps我原來也給出過一個(gè)總結(jié)。

DevOps過程概述

首先還是回顧下DevOps的簡(jiǎn)單定義如下：

DevOps（英文Development和Operations的組合）是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進(jìn)開發(fā)（應(yīng)用程序/軟件工程）、技術(shù)運(yùn)營(yíng)和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合。它的出現(xiàn)是由于軟件行業(yè)日益清晰地認(rèn)識(shí)到：為了按時(shí)交付軟件產(chǎn)品和服務(wù)，開發(fā)和運(yùn)營(yíng)工作必須緊密合作。

對(duì)于DevOps的提出已經(jīng)很多年，其主要的推動(dòng)仍來自兩個(gè)方面：

1. 業(yè)務(wù)和需求驅(qū)動(dòng)下，推動(dòng)敏捷方法論，敏捷下需要更加短周期，更快地發(fā)布和交付。

2. 技術(shù)和運(yùn)維部門需要銜接，在PaaS和容器技術(shù)發(fā)展下，進(jìn)一步推動(dòng)這部分陷阱的自動(dòng)化。

雖然是三方交融地方為DevOps的內(nèi)容，但是可以看到DevOps本身更多的是要解決兩大類協(xié)同和自動(dòng)化的問題，其一是開發(fā)部門和QA協(xié)同，其二是開發(fā)部門和運(yùn)維的協(xié)同。

對(duì)于第一個(gè)問題重點(diǎn)解決思路即常說的CI/CD持續(xù)集成和持續(xù)部署方法論，而對(duì)于第二個(gè)問題則涉及到當(dāng)前由云平臺(tái)，微服務(wù)架構(gòu)，容器技術(shù)發(fā)展推動(dòng)的自動(dòng)化發(fā)布和監(jiān)控運(yùn)維，基于敏捷研發(fā)的過程改進(jìn)等。

因此對(duì)于DevOps已經(jīng)不是簡(jiǎn)單的CI/CD，而是更多最佳實(shí)踐的融合。

持續(xù)集成和持續(xù)部署CI/CD

敏捷研發(fā)和過程協(xié)同

微服務(wù)化

基于容器云的自動(dòng)部署和動(dòng)態(tài)資源擴(kuò)展

自動(dòng)化測(cè)試技術(shù)解決QA和開發(fā)協(xié)同

雖然當(dāng)前對(duì)于微服務(wù)化，容器云等并不是實(shí)施推進(jìn)DevOps過程的必要選項(xiàng)，但是對(duì)于當(dāng)前大部分組織研發(fā)過程改進(jìn)和開發(fā)選項(xiàng)中，微服務(wù)和容器化也成為了一種默認(rèn)的標(biāo)準(zhǔn)規(guī)范。

因此今天這篇文章重點(diǎn)整理從CI/CD開始是如何疊加上各種過程能力和技術(shù)，然后逐步發(fā)展到當(dāng)前完整的DevOps過程體系。

CI/CD持續(xù)集成和持續(xù)部署

最早的團(tuán)隊(duì)軟件開發(fā)中，往往會(huì)專門安排一個(gè)開發(fā)人員或配置管理人員來人工完成編譯和部署工作。簡(jiǎn)單來說核心要做的就是就是：

• 從配置或源代碼庫(kù)update到最新代碼

• 進(jìn)行代碼編譯和構(gòu)建

• 將編譯完成的部署包部署到測(cè)試環(huán)境

而這個(gè)過程本身可以進(jìn)行自動(dòng)化處理，即人工完成的工作轉(zhuǎn)為程序自動(dòng)化來完成?？梢钥吹嚼锩鏁?huì)涉及到配置代碼庫(kù)，編譯構(gòu)建環(huán)境，測(cè)試環(huán)境三個(gè)典型資源。

其次編譯過程需要進(jìn)行自動(dòng)化，將如何進(jìn)行編譯的過程，編譯需要依賴的包，編譯構(gòu)建順序等通過xml配置文件進(jìn)行配置，后續(xù)基于該配置內(nèi)容進(jìn)行自動(dòng)化編譯。從最早的Ant到Maven基本均是該思路。

因此，最簡(jiǎn)的自動(dòng)化編譯和自動(dòng)部署，冒煙測(cè)試過程如下：

為何需要持續(xù)集成類工具？

從上圖可以看到，即使最簡(jiǎn)單的編譯構(gòu)建和部署往往也涉及到多個(gè)步驟的聯(lián)動(dòng)。如上圖需要首先連接到配置管理庫(kù)，拉群和更新到最新的源代碼；需要調(diào)用自動(dòng)化編譯腳本進(jìn)行編譯，需要觸發(fā)自動(dòng)化部署腳本進(jìn)行部署，部署后還需要調(diào)用外部自動(dòng)化測(cè)試腳本進(jìn)行測(cè)試，整體完成后還需要生成報(bào)告或發(fā)送郵件。

而整個(gè)過程需要工具來進(jìn)行自動(dòng)化組合和編排，即CI/CD類工具來完成。

每日構(gòu)建和冒煙測(cè)試

每日構(gòu)建和每日編譯的最大區(qū)別就在于是否進(jìn)行了冒煙測(cè)試，系統(tǒng)必須通過了冒煙測(cè)試才能夠算每日構(gòu)建成功。而測(cè)試人員人工介入的測(cè)試是基于冒煙測(cè)試通過的基礎(chǔ)上面的。

冒煙測(cè)試由于要驗(yàn)證整個(gè)編譯的正確性，因此冒煙測(cè)試必須是針對(duì)整個(gè)系統(tǒng)進(jìn)行冒煙測(cè)試。但冒煙測(cè)試只需要關(guān)注系統(tǒng)的主體功能即可，通過冒煙測(cè)試并不是說系統(tǒng)沒有BUG，只是說通過了冒煙測(cè)試后可以說系統(tǒng)是一個(gè)穩(wěn)定的版本，說系統(tǒng)的每日構(gòu)建是成功了，代表系統(tǒng)可以轉(zhuǎn)交專門的測(cè)試人員進(jìn)行測(cè)試了。

冒煙測(cè)試工作一般需要提前準(zhǔn)備好自動(dòng)化測(cè)試代碼或腳本，CI工具僅僅是對(duì)自動(dòng)化測(cè)試腳本進(jìn)行集成，在測(cè)試完成后輸出相應(yīng)的測(cè)試結(jié)果報(bào)告。

基于二進(jìn)制的環(huán)境遷移

對(duì)于CI/CD工具將二進(jìn)制的部署包部署到測(cè)試環(huán)境，通知開發(fā)人員進(jìn)行測(cè)試。如果開發(fā)人員在SIT測(cè)試環(huán)境測(cè)試通過，可能就需要將版本部署到UAT驗(yàn)收測(cè)試環(huán)境通知最終的用戶進(jìn)行驗(yàn)收測(cè)試。

那么這個(gè)時(shí)候是否重新再進(jìn)行編譯構(gòu)建操作，然后朝UAT環(huán)境部署？如果這樣的話顯然不合適，即無法保證測(cè)試人員在SIT測(cè)試通過的版本就是最終推送給用戶在UAT環(huán)境測(cè)試的版本。

持續(xù)集成應(yīng)該是一次構(gòu)建，形成二進(jìn)制部署包多處運(yùn)行。

因此部署版本不應(yīng)該反復(fù)構(gòu)建，而是直接用測(cè)試通過的部署版本進(jìn)行UAT環(huán)境的部署，但是這個(gè)時(shí)候往往不同環(huán)境存在的不同的配置信息，典型的即類似接口訪問地址，數(shù)據(jù)庫(kù)連接串信息等，這些信息都和環(huán)境相關(guān)。

那么就需要將這些環(huán)境相關(guān)配置從WAR包中剝離出來，在進(jìn)行環(huán)境遷移或新環(huán)境部署的時(shí)候，僅僅需要?jiǎng)討B(tài)修改這些配置文件即可。

整個(gè)過程如下：

可以看到，整個(gè)持續(xù)集成和持續(xù)部署實(shí)際要完成多個(gè)環(huán)境之間的集成和協(xié)同工作，那么支撐集成整個(gè)過程設(shè)計(jì)最好是從上面這些環(huán)境中剝離出來，應(yīng)該是單個(gè)一個(gè)Server服務(wù)器來執(zhí)行整個(gè)持續(xù)集成流水線設(shè)計(jì)和編排，調(diào)度和運(yùn)行。

進(jìn)一步解耦，持續(xù)集成節(jié)點(diǎn)和制品庫(kù)

在前面已經(jīng)談到，持續(xù)集成需要調(diào)度和編排多個(gè)環(huán)境和工具，這個(gè)已經(jīng)不再適合放在類似構(gòu)建環(huán)境上來完成，因此需要獨(dú)立出來。

其次，對(duì)于自動(dòng)化編譯完成的結(jié)果，也不適合放在構(gòu)建環(huán)境，編譯和構(gòu)建環(huán)境本身是一個(gè)臨時(shí)的環(huán)境，不適合對(duì)對(duì)構(gòu)建完成的二進(jìn)制包進(jìn)行完整的管理，版本追溯，配置等各種操作。因此制品庫(kù)也需要從構(gòu)建環(huán)境中移出，形成獨(dú)立的制品庫(kù)。

基于以上兩點(diǎn)，整體過程如下：

到了這步，基本一個(gè)完整的持續(xù)集成和持續(xù)部署就完成了。比如當(dāng)前主流的Jekins進(jìn)行持續(xù)集成和持續(xù)交付核心思路仍然如上，包括在最早版本的集成上增加了更加靈活的流水線設(shè)計(jì)，增加了和容器云能力的集成，增加了和自動(dòng)化測(cè)試工具集成等。

在傳統(tǒng)的持續(xù)集成里面，一般很少形成獨(dú)立的制品庫(kù)Server，而到了DevOps和容器云集成后，一般更加強(qiáng)調(diào)獨(dú)立的制品庫(kù)和鏡像倉(cāng)庫(kù)，這個(gè)是進(jìn)行各個(gè)環(huán)境部署，資源動(dòng)態(tài)擴(kuò)展的基礎(chǔ)。

同時(shí)持續(xù)集成Server是整個(gè)核心，通過Server來設(shè)計(jì)和編排，來統(tǒng)一調(diào)度各個(gè)能力單元，同時(shí)實(shí)現(xiàn)編譯構(gòu)建過程，和最早的測(cè)試，生產(chǎn)環(huán)境間的協(xié)同。

持續(xù)集成類：源代碼庫(kù)，構(gòu)建環(huán)境，制品庫(kù)，CI/CD環(huán)境

資源類：開發(fā)環(huán)境，測(cè)試環(huán)境，正式生產(chǎn)環(huán)境

持續(xù)集成最終就是實(shí)現(xiàn)整個(gè)開發(fā)到交付過程的完全自動(dòng)化管理。

和容器云集成

對(duì)于容器云相關(guān)內(nèi)容，可以參考網(wǎng)上的其它文章。當(dāng)持續(xù)集成和持續(xù)交付和容器云集成的時(shí)候可以看到，如下幾個(gè)變化點(diǎn)。

其一是二進(jìn)制部署包轉(zhuǎn)變?yōu)殓R像交付

其二是新增加一個(gè)制作鏡像的過程，我們一般叫打包

原來整體只有兩個(gè)動(dòng)作，編譯構(gòu)建-》部署

在和容器云集成后，整體過程會(huì)變化為三個(gè)關(guān)鍵動(dòng)作，即編譯構(gòu)建-》打包-》部署。其中打包即是鏡像制作過程，在鏡像制作完成后將鏡像推送到鏡像倉(cāng)庫(kù)。同時(shí)發(fā)起部署任務(wù)的時(shí)候，是從鏡像倉(cāng)庫(kù)里找到特定的版本，將版本部署到測(cè)試環(huán)境上。

整體過程如下：

可以看到整體持續(xù)集成和交付過程并沒有明顯的變化，僅僅在于交付的單位變成鏡像，同時(shí)增加了鏡像制作的過程。

有用底層的環(huán)境資源已經(jīng)變成容器資源池，這些資源需要進(jìn)行統(tǒng)一的管理，資源需要分配，需要基于資源使用負(fù)荷進(jìn)行動(dòng)態(tài)調(diào)度等。因此在Docker容器集群上需要有一個(gè)統(tǒng)一的管理和編排工具，這個(gè)即當(dāng)前主流的Kurbernetes來實(shí)現(xiàn)容器集群管理，容器編排。

如上圖通過Maven來實(shí)現(xiàn)代碼的構(gòu)建，同時(shí)在Jenkins中本身集成Maven，對(duì)于構(gòu)建完成的部署包會(huì)進(jìn)入到Jenkins本身的部署包倉(cāng)庫(kù)管理。這個(gè)完成后進(jìn)一步啟用Jenkins來調(diào)用底層的Docker命令生成Docker鏡像文件，這個(gè)鏡像則是我們后續(xù)做自動(dòng)部署和持續(xù)集成的關(guān)鍵鏡像文件。

在這個(gè)步驟完成后即對(duì)接到Kubernetes來實(shí)現(xiàn)Docker鏡像文件的自動(dòng)化部署和動(dòng)態(tài)調(diào)度。

在持續(xù)集成中有一個(gè)重點(diǎn)就是環(huán)境遷移，注意每次遷移的都應(yīng)該是相同的鏡像文件，而對(duì)于和環(huán)境相關(guān)的配置則單獨(dú)進(jìn)行配置或放置到OS的環(huán)境變量中。只有這樣才能夠保證最終上線的部署包就是我們最終開發(fā)和測(cè)試完成的部署包而沒有任何變動(dòng)。

如果在動(dòng)態(tài)部署的時(shí)候啟用了多個(gè)節(jié)點(diǎn)，那么還需要提供負(fù)載均衡能力。要注意的是Kubernetes本身也提供負(fù)載均衡和虛擬IP路由能力。我們最終訪問的是域名，而域名最終會(huì)解析到實(shí)際的計(jì)算節(jié)點(diǎn)。

和敏捷開發(fā)過程協(xié)同

在DevOps最佳實(shí)踐里面分為了研發(fā)管理，持續(xù)交付和技術(shù)運(yùn)營(yíng)幾個(gè)關(guān)鍵的過程域。

但是在實(shí)踐的過程中，最容易出現(xiàn)問題的不是單個(gè)技術(shù)點(diǎn)，而是跨域的協(xié)同問題，或者說研發(fā)過程管理和持續(xù)集成交付本身就是密不可分的兩個(gè)部分，我們只是為了容易理解和學(xué)習(xí)將其劃分為了不同的過程域而已。

因此流水線設(shè)計(jì)需要理清研發(fā)過程管理和自動(dòng)化持續(xù)集成間的協(xié)同關(guān)系。具體兩者的協(xié)同關(guān)系我們用下圖來進(jìn)行說明。

要明白任何一次新的編譯構(gòu)建部署完成后都涉及到測(cè)試人員測(cè)試，測(cè)試人員測(cè)試出問題后又會(huì)提交Bug，開發(fā)人員修改Bug后Check in代碼，等待下一次打包部署以形成多次迭代。整個(gè)過程最好方式就是要盡量減少大量的人工溝通協(xié)同，而是應(yīng)該通過工具鏈協(xié)同來完成。

對(duì)于傳統(tǒng)的持續(xù)集成，一般最佳實(shí)踐為每天晚上進(jìn)行自動(dòng)化構(gòu)建和冒煙測(cè)試，而對(duì)于當(dāng)期的DevOps過程，在設(shè)計(jì)完流水線后，可以手工去啟動(dòng)流水線作業(yè)，也可以自動(dòng)去執(zhí)行流水線，流水線執(zhí)行時(shí)間頻度也可以進(jìn)一步縮短。

假設(shè)我們每2個(gè)小時(shí)自動(dòng)化的執(zhí)行一次流水線作業(yè)，我們以此場(chǎng)景來做進(jìn)一步梳理。因?yàn)閷?duì)于大部分企業(yè)來說再高頻的構(gòu)建集成也不需要代碼有變動(dòng)就馬上觸發(fā)構(gòu)建打包的程度。

流水線增加啟動(dòng)檢查節(jié)點(diǎn)

雖然2小時(shí)執(zhí)行一次流水線，但是在執(zhí)行前先進(jìn)行啟動(dòng)前檢查，如果在最近2個(gè)小時(shí)內(nèi)沒有新代碼check in，那么不執(zhí)行流水線。其次，如果上一次流水線執(zhí)行實(shí)例還處于待處理或未關(guān)閉狀態(tài)的時(shí)候，同樣也不執(zhí)行流水線作業(yè)而直接跳過。

是否需要人工驗(yàn)證

流水線打包部署包括兩個(gè)方面，一個(gè)是新功能提交或新bug解決，只有這種情況才需要人工驗(yàn)證。因此一次流水線執(zhí)行如果沒有新需求或Bug狀態(tài)變化，那么應(yīng)該直接跳過人工驗(yàn)證節(jié)點(diǎn)并關(guān)閉。反之，則應(yīng)該跳轉(zhuǎn)到待人工驗(yàn)證環(huán)節(jié)。

需求和缺陷的管理

要注意到新需求和新缺陷都應(yīng)該提交，而且都有狀態(tài)，需求細(xì)分到具體的需求功能點(diǎn)，同時(shí)測(cè)試人員提交的缺陷應(yīng)該對(duì)應(yīng)到具體的需求功能點(diǎn)上面。一個(gè)需求開發(fā)完成后，需求本身也到待驗(yàn)證狀態(tài)，但是一個(gè)待驗(yàn)證的需求是否能夠關(guān)閉則必須是該需求下面所有的bug都解決完成后才能夠關(guān)閉。

需求和缺陷狀態(tài)的變化

開發(fā)人員首先是將需求或缺陷完成，并在本機(jī)進(jìn)行自測(cè)通過，然后將代碼check in到配置管理庫(kù)。同時(shí)手工將需求或缺陷狀態(tài)處理到待部署狀態(tài)。在流水線啟動(dòng)后，如果整個(gè)構(gòu)建打包和部署成功，則在成功完成應(yīng)用部署后，將待部署狀態(tài)的需求或bug轉(zhuǎn)到待驗(yàn)證狀態(tài)。在部署完成后測(cè)試人員可以看到待驗(yàn)證的bug或需求，那么他進(jìn)入當(dāng)前的測(cè)試環(huán)境一定是最新的可以進(jìn)行缺陷驗(yàn)證的環(huán)境。

變更驅(qū)動(dòng)的版本開發(fā)和流水線設(shè)計(jì)

對(duì)于一個(gè)變更，如果只涉及到一個(gè)微服務(wù)模塊的變動(dòng)，那么相當(dāng)來說整個(gè)持續(xù)集成過程是很簡(jiǎn)單的，我們也很容易在DevOps上完成這個(gè)流水線設(shè)計(jì)并執(zhí)行。但是如果涉及多個(gè)整個(gè)過程就復(fù)雜了很多。

我們舉例來說，現(xiàn)在接收到一個(gè)或多個(gè)用戶變更需求，經(jīng)過需求分析后發(fā)現(xiàn)實(shí)際影響三個(gè)微服務(wù)模塊都需要進(jìn)行配套變更才能夠完成。那么我們可以規(guī)劃一個(gè)研發(fā)小版本來解決，即首先該需求就會(huì)拆分，并對(duì)應(yīng)到三個(gè)微服務(wù)模塊變更的任務(wù)。

在這種場(chǎng)景下變更驅(qū)動(dòng)場(chǎng)景下，我們可以保留原來的大而全的頂層流水線，但是對(duì)應(yīng)沒有代碼變化版本不再執(zhí)行編譯構(gòu)建操作。

一個(gè)大應(yīng)用涉及多個(gè)微服務(wù)，務(wù)必要執(zhí)行無變更不重新編譯構(gòu)建原則。但是我們實(shí)際看到在很多DevOps實(shí)踐中，一個(gè)變更版本開發(fā)，往往也會(huì)對(duì)沒有變動(dòng)的微服務(wù)重新構(gòu)建打包。

即大流水線執(zhí)行到子流水線的時(shí)候自動(dòng)跳過一些子流水線的執(zhí)行。當(dāng)然我們也可以重新規(guī)劃一個(gè)新的頂層流水線，只選擇有變更的三個(gè)微服務(wù)模塊進(jìn)行編排設(shè)計(jì)，同時(shí)根據(jù)依賴關(guān)系定義好三個(gè)模塊本身的編譯構(gòu)建順序。

整個(gè)頂層流水線執(zhí)行的時(shí)候就會(huì)將三個(gè)變更模塊全部編譯構(gòu)建并打包部署，然后驅(qū)動(dòng)后面的自動(dòng)化測(cè)試，人工測(cè)試和驗(yàn)證。整個(gè)需求的實(shí)現(xiàn)，缺陷的修改過程應(yīng)該是完整可視的。簡(jiǎn)單來說，基于這個(gè)變更小版本，提交的幾個(gè)需求變更點(diǎn)當(dāng)前已經(jīng)實(shí)現(xiàn)了幾個(gè)，究竟還有多少缺陷在處理，我們應(yīng)該一清二楚地了解到。

和測(cè)試管理集成

對(duì)于測(cè)試管理也是整個(gè)DevOps過程實(shí)踐中的一個(gè)關(guān)鍵內(nèi)容。其中主要包括三類。

靜態(tài)代碼合規(guī)性，安全性檢測(cè)

自動(dòng)化測(cè)試(接口，UI）

自動(dòng)化性能測(cè)試

自動(dòng)化測(cè)試是把以人為驅(qū)動(dòng)的測(cè)試行為轉(zhuǎn)化為機(jī)器執(zhí)行的一種過程，在預(yù)設(shè)條件下運(yùn)行系統(tǒng)或應(yīng)用程序，執(zhí)行測(cè)試并評(píng)估測(cè)試結(jié)果，以達(dá)到節(jié)省資源和人力，提高測(cè)試效率和準(zhǔn)確性，主要包括了自動(dòng)化設(shè)計(jì)，自動(dòng)化開發(fā)，自動(dòng)化執(zhí)行和自動(dòng)化分析。

對(duì)于自動(dòng)化測(cè)試可以看到，對(duì)于服務(wù)接口和代碼級(jí)的自動(dòng)化測(cè)試相對(duì)來說比較容易實(shí)現(xiàn)，但是對(duì)于前端和UI級(jí)的自動(dòng)化測(cè)試相對(duì)來說就比較困難些。因此對(duì)于前期實(shí)踐，我們也是建議先實(shí)現(xiàn)接口服務(wù)和代碼級(jí)的自動(dòng)化測(cè)試，再來靠前端UI的自動(dòng)化測(cè)試。

對(duì)于性能測(cè)試由于可以提前錄制腳本，相對(duì)來說自動(dòng)化測(cè)試實(shí)現(xiàn)起來比較容易。

測(cè)試任務(wù)和流水線設(shè)計(jì)

一般來講，在進(jìn)行編譯構(gòu)建前，當(dāng)從配置庫(kù)update到最新代碼后就可以進(jìn)行代碼靜態(tài)檢查，安全類檢查任務(wù)執(zhí)行。

在編譯構(gòu)建完成后，如果構(gòu)建成功，可以執(zhí)行后續(xù)的自動(dòng)化測(cè)試任務(wù)腳本。其中本身又建議優(yōu)先執(zhí)行類似Junit等單元測(cè)試腳本和接口類自動(dòng)化測(cè)試腳本。而對(duì)于性能測(cè)試實(shí)際并不需要每次持續(xù)集成都執(zhí)行，因此一般涉及到性能測(cè)試的場(chǎng)景需要單獨(dú)設(shè)計(jì)獨(dú)立的流水線執(zhí)行。

從持續(xù)集成到完整DevOps支撐

在整個(gè)DevOps最佳實(shí)踐里面持續(xù)集成/持續(xù)部署仍然是最基礎(chǔ)的，為了實(shí)現(xiàn)整個(gè)研發(fā)生命周期的過程管理和持續(xù)交付，那么需要實(shí)現(xiàn)和敏捷研發(fā)過程管理的集成協(xié)同，需要實(shí)現(xiàn)和后端容器云平臺(tái)的集成和協(xié)同。

當(dāng)構(gòu)建一個(gè)完整的DevOps能力支撐平臺(tái)的時(shí)候，更多的是對(duì)上面談到的各種能力進(jìn)行整合和集成，實(shí)現(xiàn)一個(gè)完整的端到端過程能力支撐。

DevOps平臺(tái)本身是一個(gè)諸多開源工具鏈的一個(gè)整合和協(xié)同平臺(tái)，其核心不在于提供獨(dú)立的類似編譯構(gòu)建，部署等能力，而是對(duì)這些能力進(jìn)行整合和協(xié)同。同時(shí)在整合這些能力的時(shí)候需要考慮多租戶，資源的管理，配置管理，任務(wù)調(diào)度等一系列工作。

一個(gè)DevOps支撐平臺(tái)在搭建總體架構(gòu)的時(shí)候可以看到，其核心更多的是圍繞持續(xù)交付進(jìn)行的各種能力的集成和自動(dòng)化，而不是說其本身新創(chuàng)作了什么能力。對(duì)于這種集成本身包括幾個(gè)關(guān)鍵部分。

其一是和Docker容器化平臺(tái)的集成，以實(shí)現(xiàn)自動(dòng)化部署和環(huán)境間的動(dòng)態(tài)遷移，包括灰度發(fā)布，資源動(dòng)態(tài)調(diào)度，集群等關(guān)鍵能力。其二是和微服務(wù)平臺(tái)的集成，類似開源的SpringCloud平臺(tái)中的注冊(cè)中心，微服務(wù)網(wǎng)關(guān)的集成。其三包括和前面提到的PaaS平臺(tái)各技術(shù)組件和服務(wù)的集成。其四則是對(duì)持續(xù)交付過程中的涉及到的各類工具鏈的集成，包括了配置和代碼管理，代碼靜態(tài)檢查，自動(dòng)化編譯構(gòu)建，自動(dòng)化測(cè)試，自動(dòng)化運(yùn)維，自動(dòng)化監(jiān)控，日志管理等各種工具的集成。

一個(gè)DevOps平臺(tái)需要提供對(duì)源代碼管理，開發(fā)，編譯構(gòu)建，打包，部署，測(cè)試，運(yùn)維完整的能力支撐，同時(shí)通過流水線設(shè)計(jì)將這些任務(wù)過程進(jìn)行自動(dòng)化串聯(lián)。一個(gè)流水線既可以是完全的自動(dòng)化流水線，也可以包括人工處理和檢查節(jié)點(diǎn)。流水線可以對(duì)上述動(dòng)作和任務(wù)進(jìn)行可視化的設(shè)計(jì)和編排。

感謝閱讀