在前面提到云原生完整技術(shù)解決方案的時(shí)候，已經(jīng)提到了公司DevOps技術(shù)支撐平臺(tái)和容器云解決方案。但是DevOps絕對(duì)不是一個(gè)簡(jiǎn)單的開(kāi)源技術(shù)集成或者技術(shù)解決方案，而是結(jié)合本身的微服務(wù)架構(gòu)優(yōu)化，敏捷開(kāi)發(fā)的企業(yè)研發(fā)過(guò)程改進(jìn)和持續(xù)優(yōu)化。

敏捷研發(fā)和CI/CD持續(xù)集成過(guò)程脫節(jié)，往往才是當(dāng)前最大的一個(gè)問(wèn)題點(diǎn)。

今天談的重點(diǎn)不是DevOps具體的底層開(kāi)源工具鏈和技術(shù)，而是對(duì)于敏捷研發(fā)，微服務(wù)如何更好的和DevOps過(guò)程形成一個(gè)高度協(xié)同的整體。在這個(gè)過(guò)程實(shí)踐中，可能會(huì)形成多篇文章，都是對(duì)我們實(shí)踐過(guò)程的一些問(wèn)題總結(jié)，思考和復(fù)盤。

先從單體微服務(wù)拆分談起

圖片

最早的時(shí)候，我們自己的DevOps管控治理平臺(tái)拆分為20多個(gè)微服務(wù)，20多個(gè)微服務(wù)每個(gè)都是獨(dú)立的項(xiàng)目，獨(dú)立設(shè)計(jì)流水線，部署在獨(dú)立的容器里面。可想而知，整個(gè)后續(xù)集成，部署和運(yùn)維管控的復(fù)雜度有多大。

在去年，團(tuán)隊(duì)進(jìn)行了重構(gòu)，將微服務(wù)進(jìn)行了合并，在合并完成后包括基礎(chǔ)組件和能力中心微服務(wù)，一共在10個(gè)左右的微服務(wù)模塊。合并到這個(gè)粒度后基本才處于一種可控的狀態(tài)。

微服務(wù)拆分的顆粒度實(shí)際上還和你團(tuán)隊(duì)規(guī)模有關(guān)系，當(dāng)你團(tuán)隊(duì)規(guī)模本身就不大的時(shí)候一定不要拆分的太細(xì)，一個(gè)人如果就管理多個(gè)微服務(wù)，實(shí)際當(dāng)初進(jìn)行微服務(wù)劃分，希望進(jìn)行的邊界和解耦往往根本就無(wú)法做到。

在合并完成后仍然存在兩個(gè)問(wèn)題。

其一是數(shù)據(jù)庫(kù)仍然沒(méi)有拆分是一個(gè)大數(shù)據(jù)庫(kù)。如果從理想的微服務(wù)架構(gòu)來(lái)說(shuō)，并沒(méi)有做到完全的微服務(wù)化，數(shù)據(jù)庫(kù)層面沒(méi)有解耦。

但是當(dāng)你數(shù)據(jù)庫(kù)本身就沒(méi)有海量并發(fā)和數(shù)據(jù)量大幅擴(kuò)展的壓力時(shí)候，你的數(shù)據(jù)庫(kù)為啥要拆分？數(shù)據(jù)庫(kù)本身不要為了拆分而拆分，數(shù)據(jù)庫(kù)的拆分更多是為了擴(kuò)展性的需求。當(dāng)構(gòu)建的應(yīng)用在DB層本身沒(méi)有太大的性能壓力的時(shí)候，實(shí)際沒(méi)必要馬上就去做數(shù)據(jù)庫(kù)的拆分。

其次，我在很早就提出了微服務(wù)域的概念，即使上層是10個(gè)微服務(wù)，你的數(shù)據(jù)庫(kù)本身也不需要就一定拆分為10個(gè)，而是應(yīng)該根據(jù)微服務(wù)域的劃分來(lái)進(jìn)行數(shù)據(jù)庫(kù)的拆分。比如上層的編譯，構(gòu)建，流水線，交付管理等微服務(wù)，完全可以合并在一個(gè)數(shù)據(jù)庫(kù)里面。

其二是在前后端分離情況下，整個(gè)平臺(tái)的BS前端合并在一個(gè)項(xiàng)目里面。這個(gè)我個(gè)人認(rèn)為并不太合理，也就是說(shuō)一個(gè)功能如果涉及到前端應(yīng)用有改動(dòng)，那么整個(gè)前端應(yīng)用都需要重新部署。比如資源管理部分的前端界面變化了，實(shí)際整個(gè)應(yīng)用前端都需要重新部署，那么對(duì)于流水線，資產(chǎn)庫(kù)這些微服務(wù)模塊對(duì)應(yīng)的前端是否造成影響并不清楚。

也就是說(shuō)前端并沒(méi)有做到完全的解耦。

如果你是開(kāi)發(fā)一個(gè)APP應(yīng)用功能，那么前端整合為一個(gè)項(xiàng)目無(wú)可厚非，但是如果是傳統(tǒng)的企業(yè)級(jí)的PC端的BS應(yīng)用，最好的方式仍然是前端需要進(jìn)行分離。

從需求用戶故事到任務(wù)拆分

圖片

在敏捷研發(fā)里面我們強(qiáng)調(diào)基于用戶故事進(jìn)行全流程的跟蹤。我們將收集的需求進(jìn)行分析，將需求定義為用戶故事或需求點(diǎn)，同時(shí)將需求規(guī)劃到具體的項(xiàng)目版本中。這個(gè)是最基本的產(chǎn)品-項(xiàng)目-項(xiàng)目版本的分解過(guò)程。

當(dāng)需求規(guī)劃到項(xiàng)目版本后，一個(gè)重點(diǎn)就是將需求轉(zhuǎn)變?yōu)榫唧w的任務(wù)。你采取的不同研發(fā)過(guò)程，不同的管控顆粒度下，實(shí)際上任務(wù)的分解本身是有標(biāo)準(zhǔn)可以遵循的。如果從傳統(tǒng)的方式下，任何一個(gè)需求點(diǎn)往往包括了如下任務(wù)分解：

1.資源配置功能需求

1.1 資源配置需求文檔編寫

1.2 資源配置功能開(kāi)發(fā)

1.3 資源配置測(cè)試用例編寫

1.4 資源配置功能測(cè)試

這是最常見(jiàn)的一個(gè)任務(wù)分解安排。

在敏捷開(kāi)發(fā)和前后端分離下，你可以看到一個(gè)功能的開(kāi)發(fā)同時(shí)涉及到前端和后端，后端開(kāi)發(fā)完成后輸出的是接口，前端基于接口進(jìn)行集成和聯(lián)調(diào)。在這個(gè)過(guò)程中測(cè)試人員又需要接入進(jìn)行測(cè)試，其一是針對(duì)后端開(kāi)發(fā)完成的接口測(cè)試，其二是針對(duì)前端完成的功能做黑盒測(cè)試。那么基于這個(gè)思路，你會(huì)看到任何一個(gè)功能的實(shí)現(xiàn)都可以分解為如下：

1.資源配置管理功能實(shí)現(xiàn)

1.1. 需求開(kāi)發(fā)-》需求人員

1.2 后端功能和API接口開(kāi)發(fā)-》后端開(kāi)發(fā)

1.3 API接口測(cè)試-》測(cè)試人員

1.4 前端功能開(kāi)發(fā)和集成-》前端開(kāi)發(fā)

1.5 功能整體測(cè)試-》測(cè)試人員

當(dāng)思考到這里的時(shí)候，實(shí)際我們希望的是，對(duì)于敏捷研發(fā)項(xiàng)目管理工具，在你的開(kāi)發(fā)模式確定后，基于某個(gè)需求點(diǎn)的子任務(wù)拆分應(yīng)該是自動(dòng)化進(jìn)行的?；蛘哒f(shuō)可以基于標(biāo)準(zhǔn)的開(kāi)發(fā)任務(wù)分配模板進(jìn)行自動(dòng)的子任務(wù)生成。

如果做到這點(diǎn)，實(shí)際上還是沒(méi)有辦法解決問(wèn)題。因?yàn)槲覀內(nèi)蝿?wù)的跟蹤實(shí)際上還是按照單個(gè)任務(wù)的方式，按未開(kāi)發(fā)-進(jìn)行中-已完成等任務(wù)狀態(tài)進(jìn)行看板跟蹤。

但是我們實(shí)際需要的是按照開(kāi)發(fā)模式關(guān)鍵技術(shù)進(jìn)行任務(wù)跟蹤。比如前面談到的我們跟蹤的是用戶故事或需求點(diǎn)，我們關(guān)心的狀態(tài)是當(dāng)前用戶故事處于需求開(kāi)發(fā)階段，還是后端開(kāi)發(fā)，還是前端開(kāi)發(fā)集成階段。這個(gè)才是關(guān)鍵的看板跟蹤點(diǎn)。

也就是說(shuō)傳統(tǒng)看板你看到的是類似下圖：

圖片

但是實(shí)際上我們希望看到的是基于需求或用戶故事點(diǎn)為核心的看板。這個(gè)看板并不是現(xiàn)實(shí)具體的子任務(wù)，而是只到任務(wù)基本，子任務(wù)影響到的是看板面板卡片的狀態(tài)。

圖片

比如上圖，我們可以很清楚的看到當(dāng)前迭代版本一共規(guī)劃了11個(gè)功能點(diǎn)，同時(shí)每個(gè)功能點(diǎn)當(dāng)前在哪個(gè)階段或狀態(tài)。其次，對(duì)于某個(gè)崗位角色的人上來(lái)，也可以很清楚的看到他當(dāng)前自己的關(guān)鍵todo事項(xiàng)，他要做的是盡快完成自己泳道的事情，將任務(wù)狀態(tài)轉(zhuǎn)移到下個(gè)階段。也就是說(shuō)當(dāng)做了如上改進(jìn)了時(shí)候，才能夠更好的做到敏捷研發(fā)模式和敏捷任務(wù)看板管理的一個(gè)融合協(xié)同。

從需求變更到項(xiàng)目版本規(guī)劃

在這里我們將已有功能的需求變更和新增的小需求都納入到需求變更的范疇。當(dāng)前談CI/CD持續(xù)集成和持續(xù)部署，更多的都是應(yīng)用系統(tǒng)上線后的缺陷修改，需求變更引發(fā)的迭代版本開(kāi)發(fā)和部署操作。

因此需求變更才是后續(xù)軟件應(yīng)用持續(xù)集成的一個(gè)基礎(chǔ)輸入。

圖片

在前面談產(chǎn)品和項(xiàng)目?jī)杉?jí)流水線設(shè)計(jì)的時(shí)候，我就談到了一個(gè)產(chǎn)品拆分為了多個(gè)微服務(wù)模塊，每個(gè)微服務(wù)模塊都相對(duì)獨(dú)立和解耦。

但是用戶最終看到的仍然是整個(gè)應(yīng)用系統(tǒng)。

一次需求變更過(guò)來(lái)后，我們通過(guò)分析最終需要確定的就是涉及到哪幾個(gè)微服務(wù)模塊需要變更。在分析清楚后，最好的方式就是僅僅變更的微服務(wù)模塊需要重新進(jìn)行持續(xù)編譯，構(gòu)建和部署集成，而對(duì)于沒(méi)有變更的模塊不應(yīng)該進(jìn)行重新的編譯構(gòu)建操作。

微服務(wù)下對(duì)傳統(tǒng)單體應(yīng)用解耦后，最基本要做到的就是某個(gè)微服務(wù)如果沒(méi)有變更，就不應(yīng)該去重復(fù)地進(jìn)行編譯和部署，任何重復(fù)多余的編譯部署操作往往都容易引入新的缺陷或問(wèn)題。

比如上圖的例子，一次需求變更過(guò)來(lái)我們規(guī)劃V2版本，但是實(shí)際上只有綠色的三個(gè)微服務(wù)模塊需要進(jìn)行版本升級(jí)和變更，而灰色的三個(gè)并沒(méi)有變更，不用進(jìn)行重新的編譯構(gòu)建等操作。在這個(gè)時(shí)候容器管理部分的功能在應(yīng)用發(fā)版后不需要進(jìn)行回歸測(cè)試，即使容器管理部分功能出現(xiàn)問(wèn)題，我們也應(yīng)該追溯容器暴露接口相關(guān)的外圍消費(fèi)和調(diào)用。

當(dāng)這個(gè)思考清楚后，你會(huì)看到需求變更納入到項(xiàng)目版本，那么我們實(shí)際最關(guān)心的是當(dāng)前的項(xiàng)目版本整體進(jìn)展，這個(gè)進(jìn)展不是只是需求，任務(wù)和缺陷的研發(fā)管理過(guò)程和任務(wù)，同時(shí)也應(yīng)該包括了整個(gè)CI/CD過(guò)程進(jìn)展。

簡(jiǎn)單來(lái)說(shuō)就是：研發(fā)管理過(guò)程和CI/CD過(guò)程應(yīng)該基于項(xiàng)目版本主線形成一個(gè)完整的類似看板一樣的管理視圖。這個(gè)視圖就是整個(gè)敏捷團(tuán)隊(duì)的工作界面。

對(duì)于這個(gè)可視化看板，簡(jiǎn)單構(gòu)思應(yīng)該如下：

圖片

也就是說(shuō)我們希望看到一個(gè)完整的基于項(xiàng)目當(dāng)前版本的看板視圖，在這個(gè)視圖一個(gè)是可以看到當(dāng)前需求，任務(wù)的直接進(jìn)展情況；其次是可以清楚地看到涉及到當(dāng)前項(xiàng)目版本的編譯構(gòu)建和部署情況。

這個(gè)也是我們進(jìn)一步將研發(fā)任務(wù)管理的狀態(tài)和CI/CD過(guò)程進(jìn)行集成的基礎(chǔ)。

比如我們?cè)谇懊婧芏辔恼吕锩嬲劦降摹?/p>

開(kāi)發(fā)人員對(duì)一個(gè)開(kāi)發(fā)任務(wù)反饋完成，這個(gè)時(shí)候任務(wù)本身的狀態(tài)應(yīng)該是在待部署狀態(tài)，這個(gè)是一個(gè)看板上的隱藏狀態(tài)并不需要人工去關(guān)心。而只有流水線執(zhí)行成功后相關(guān)的任務(wù)才會(huì)從待部署狀態(tài)轉(zhuǎn)移到待測(cè)試狀態(tài)。

也就是說(shuō)開(kāi)發(fā)完成任務(wù)，這個(gè)功能本身仍然在開(kāi)發(fā)人員的看板中，只有后臺(tái)的流水線執(zhí)行成功，完成了功能的自動(dòng)部署后，該需求功能才會(huì)自動(dòng)轉(zhuǎn)移到測(cè)試中這個(gè)看板。

這些關(guān)鍵環(huán)節(jié)必須系統(tǒng)自動(dòng)銜接。

否則一個(gè)功能開(kāi)發(fā)反饋已經(jīng)完成，但是測(cè)試人員上去發(fā)現(xiàn)并不能測(cè)試，最終追溯才看到流水線任務(wù)實(shí)際執(zhí)行失敗，導(dǎo)致開(kāi)發(fā)完成的功能并沒(méi)有成功部署。這些都勢(shì)必會(huì)導(dǎo)致大量無(wú)效的人工溝通和協(xié)同工作。

流水線觸發(fā)和構(gòu)建頻率

圖片

在DevOps實(shí)踐方法論里面，始終在強(qiáng)調(diào)隨時(shí)隨地的觸發(fā)構(gòu)建，一天不需要去約束構(gòu)建次數(shù)，只要代碼一check in就應(yīng)該觸發(fā)流水線編譯構(gòu)建流程進(jìn)行構(gòu)建。

在講這個(gè)問(wèn)題前，我想先談兩個(gè)例子。

一個(gè)是在游樂(lè)園里面做一個(gè)旋轉(zhuǎn)的游樂(lè)設(shè)施，剛開(kāi)始的時(shí)候速度不快，完全能夠接受。但是后面速度越來(lái)越快，最后感覺(jué)就是腦袋一陣眩暈。實(shí)際上這個(gè)設(shè)施可以轉(zhuǎn)得更加快或者說(shuō)頻度跟高，但是就個(gè)人來(lái)說(shuō)，你始終會(huì)有一個(gè)你能夠接受的極限值，超過(guò)了就暈。個(gè)人由于各自的身體素質(zhì)差異，實(shí)際上這個(gè)極限值本身存在不同。

還有一個(gè)我們寫文章的例子。

比如我寫文章，我專門找了一個(gè)編輯幫我進(jìn)行審核和修訂，我既可以是每寫一小段就發(fā)給對(duì)方讓他修改，也可以是我每天或每周發(fā)送一次給對(duì)方讓對(duì)方統(tǒng)一修改。如果我每寫一個(gè)小時(shí)就發(fā)送一次，那么對(duì)方馬上反饋問(wèn)題后，我實(shí)際的寫作過(guò)程都在隨時(shí)被打斷，這個(gè)顯然是對(duì)我正常寫作造成影響。

圖片

回到我們構(gòu)建頻率這件事情上。

實(shí)際上構(gòu)建方式或頻率包括了代碼check in就自動(dòng)構(gòu)建，也可以是人手工發(fā)起構(gòu)建，還可以是每天或每半天定時(shí)構(gòu)建一次。如果按DevOps最佳實(shí)踐方法是代碼提交即構(gòu)建，但是我要說(shuō)的是這種方法并不適合大部分的團(tuán)隊(duì)，什么原因呢？

其一是團(tuán)隊(duì)和個(gè)人本身的成熟度和敏捷度就無(wú)法適應(yīng)這種高頻率構(gòu)建，工具高頻率容易，但是人要高頻率需要的是高度的自律。其二是當(dāng)隨時(shí)都在構(gòu)建的時(shí)候，你發(fā)現(xiàn)開(kāi)發(fā)人員隨時(shí)都在解決構(gòu)建過(guò)程中出現(xiàn)的問(wèn)題或依賴沖突，導(dǎo)致開(kāi)發(fā)真正專注在編碼上的時(shí)間越來(lái)越少，也就是是高頻率構(gòu)建極其容器導(dǎo)致我們開(kāi)發(fā)時(shí)間碎片化，這個(gè)顯然是開(kāi)發(fā)的大忌。

當(dāng)做了上述思考后，最佳的方式仍然是按天或半天定時(shí)構(gòu)建，同時(shí)對(duì)于關(guān)鍵bug的解決根據(jù)業(yè)務(wù)驅(qū)動(dòng)由測(cè)試手工發(fā)起流水線運(yùn)行。

很多互聯(lián)網(wǎng)應(yīng)用每2到3天就再發(fā)布和迭代版本，但是對(duì)于企業(yè)內(nèi)部信息化應(yīng)用，實(shí)際上遠(yuǎn)遠(yuǎn)不需要如此敏捷和高頻，因此我們持續(xù)集成和構(gòu)建的頻率也無(wú)須如此。

當(dāng)團(tuán)隊(duì)和個(gè)人自身的能力和成熟度達(dá)到后，我們可以進(jìn)一步縮短構(gòu)建頻率，比如從半天到每2個(gè)小時(shí)一次構(gòu)建。同時(shí)對(duì)于構(gòu)建頻率的縮短往往還伴隨著PMS任務(wù)顆粒度的細(xì)化，你原來(lái)的任務(wù)顆粒度是1周或2到3天，那么新的顆粒度則可能是2小時(shí)或4小時(shí)。

父子流水線和環(huán)境遷移

圖片

首先再次強(qiáng)調(diào)一個(gè)關(guān)鍵點(diǎn)，即：

對(duì)于CI/CD的價(jià)值一定體現(xiàn)在跨環(huán)境的自動(dòng)遷移部署能力，而不是單個(gè)環(huán)境的自動(dòng)化編譯構(gòu)建和應(yīng)用部署。編譯構(gòu)建的過(guò)程只有一次，形成的是二進(jìn)制文件包；而環(huán)境遷移可以多次并靈活編排，環(huán)境遷移不需要重新編譯構(gòu)建，最終確保基礎(chǔ)依賴的一致性。

也正是如此，環(huán)境遷移一定是我們流水線設(shè)計(jì)編排的一個(gè)重點(diǎn)。

比如最常見(jiàn)的業(yè)務(wù)場(chǎng)景，我們準(zhǔn)備了SIT集成測(cè)試環(huán)境和UAT用戶驗(yàn)收測(cè)試環(huán)境，當(dāng)某個(gè)版本的軟件開(kāi)發(fā)在SIT環(huán)境完成集成測(cè)試，所有的Bug都修復(fù)后。我們需要將軟件部署到UAT環(huán)境，并通知用戶進(jìn)行驗(yàn)收測(cè)試。

如何確保用戶驗(yàn)收測(cè)試的版本就是我們SIT測(cè)試通過(guò)的版本？

即前面談到的基于二進(jìn)制和鏡像文件的遷移，對(duì)于UAT環(huán)境部署重新編譯部署，而僅僅是鏡像文件在UAT環(huán)境的部署，這是CI/CD強(qiáng)調(diào)的一個(gè)重點(diǎn)。

圖片

那么問(wèn)題的復(fù)雜度在哪里？

即前面談到的傳統(tǒng)的一個(gè)單體應(yīng)用系統(tǒng)以及拆分為了10個(gè)微服務(wù)模塊，每個(gè)微服務(wù)都可以獨(dú)立編譯構(gòu)建，打包和部署。每個(gè)微服務(wù)都有自己各自的流水線設(shè)計(jì)。

但是實(shí)際上就一個(gè)項(xiàng)目版本來(lái)說(shuō)，我們只關(guān)注這個(gè)項(xiàng)目版本的完整性。比如這個(gè)項(xiàng)目版本僅僅涉及到3個(gè)微服務(wù)模塊要變更，那么在SIT測(cè)試通過(guò)后就應(yīng)該將這三個(gè)微服務(wù)模塊的最新測(cè)試通過(guò)版本遷移部署到UAT環(huán)境。

也就是說(shuō)應(yīng)該在微服務(wù)流水線基礎(chǔ)上增加一個(gè)對(duì)應(yīng)產(chǎn)品或項(xiàng)目版本的流水線。編譯或構(gòu)建是以微服務(wù)為最小顆粒度單位，但是環(huán)境遷移構(gòu)建，是以產(chǎn)品或項(xiàng)目版本為單位進(jìn)行。

我們還是回到前面的場(chǎng)景，比如DevOps平臺(tái)研發(fā)規(guī)劃了V2版本，這個(gè)版本涉及到門戶管理，研發(fā)管理，持續(xù)集成三個(gè)微服務(wù)模塊的變更和發(fā)布。

對(duì)于上面三個(gè)微服務(wù)模塊本身就已經(jīng)有自己的獨(dú)立編譯構(gòu)建部署流水線任務(wù)。

那么現(xiàn)在重點(diǎn)就是基于本次規(guī)劃的項(xiàng)目版本V2，構(gòu)建一個(gè)父流水線，同時(shí)將已經(jīng)有的三個(gè)微服務(wù)模塊流水線掛接進(jìn)來(lái)，形成一個(gè)完整的父子流水線模式。

也就是說(shuō)在父流水線上我們只會(huì)編排環(huán)境遷移的關(guān)鍵節(jié)點(diǎn)，比如：開(kāi)發(fā)測(cè)試環(huán)境-》SIT環(huán)境-》UAT環(huán)境

我們會(huì)在流水線上設(shè)置由測(cè)試人員參與的手工審核和處理節(jié)點(diǎn)，當(dāng)測(cè)試人員確認(rèn)SIT測(cè)試通過(guò)的時(shí)候，我才進(jìn)行自動(dòng)化的環(huán)境遷移動(dòng)作。同時(shí)父節(jié)點(diǎn)必須是在各個(gè)子流水線運(yùn)行成功后再跳轉(zhuǎn)到下一個(gè)活動(dòng)節(jié)點(diǎn)狀態(tài)。

比如前面談到發(fā)起一次父流水線運(yùn)行，那么先去執(zhí)行各個(gè)子流水線，子流水線如何全部執(zhí)行成功則將父流水線狀態(tài)轉(zhuǎn)移到待測(cè)試狀態(tài)。測(cè)試人員在完成一輪測(cè)試后，如果不通過(guò)則進(jìn)行不通過(guò)處理，將流水線退回到初始狀態(tài)。

同時(shí)在進(jìn)入流水線視圖的時(shí)候，可以清楚地看到當(dāng)前整體流水線的執(zhí)行情況，即當(dāng)前項(xiàng)目版本涉及到幾個(gè)子流水線，各自對(duì)應(yīng)哪個(gè)微服務(wù)模塊，每個(gè)子流水線是否允許成功，如果失敗可以進(jìn)入到詳細(xì)的流水線任務(wù)查看界面查看原因等。