01. 需求管理模型和敏穩(wěn)雙態(tài)開(kāi)發(fā)

在研發(fā)產(chǎn)品之前，我們都需要先了解客戶的需求。常見(jiàn)的需求理論模型有三種，可基于不同業(yè)務(wù)和產(chǎn)品復(fù)雜度的需求層次結(jié)構(gòu)進(jìn)行選擇。

• 簡(jiǎn)單的業(yè)務(wù)和產(chǎn)品：拆分成兩層，產(chǎn)品需求?技術(shù)任務(wù)
• 典型的業(yè)務(wù)和產(chǎn)品：拆分成三層，業(yè)務(wù)需求?產(chǎn)品需求?技術(shù)任務(wù)
• 復(fù)雜的業(yè)務(wù)和產(chǎn)品：拆分成四層，業(yè)務(wù)需求?產(chǎn)品特性?產(chǎn)品需求?技術(shù)任務(wù)

那么如何將需求理論模型跟現(xiàn)有的流程結(jié)合起來(lái)呢？

下圖為某大廠公布的研發(fā)效能白皮書中的一張圖，根據(jù)需求來(lái)源的不同和不同人員所需要具備的能力，把產(chǎn)品管理分成三個(gè)層次，通過(guò)流程與工具相結(jié)合進(jìn)行描述或使用項(xiàng)目管理工具。

我們對(duì)標(biāo)業(yè)界最佳實(shí)踐，爭(zhēng)做國(guó)內(nèi)最好的項(xiàng)目管理工具，不僅既支持瀑布開(kāi)發(fā)模式，還支持敏捷開(kāi)發(fā)模式；同時(shí)具備存儲(chǔ)文檔、Wiki等功能。也就是說(shuō)，在項(xiàng)目管理和需求管理方面，我們的平臺(tái)能涵蓋95%以上的使用場(chǎng)景（掃描文末海報(bào)二維碼，立即申請(qǐng)?jiān)囉茫＼浖_(kāi)發(fā)流程在這兒不過(guò)多介紹，業(yè)界用的最多的就是瀑布開(kāi)發(fā)模式、敏捷開(kāi)發(fā)模式和DevOps開(kāi)發(fā)模式。盡管常見(jiàn)的開(kāi)發(fā)模式是這些，但是大多數(shù)工具只支持敏捷開(kāi)發(fā)模式，很少有工具支持雙態(tài)（既支持瀑布，又支持敏捷開(kāi)發(fā)模式）模式。

02. DevOps涵蓋產(chǎn)品全生命周期

有些人可能對(duì)敏捷、DevOps等涵蓋的領(lǐng)域有些模糊。一般來(lái)講，敏捷解決的是業(yè)務(wù)部門和研發(fā)部門之間的矛盾，DevOps解決的是開(kāi)發(fā)測(cè)試運(yùn)維這一過(guò)程中可能遇到的沖突，涵蓋的是整個(gè)產(chǎn)品全生命周期。

隨著公司規(guī)模的擴(kuò)大，開(kāi)發(fā)層面常面臨以下問(wèn)題：

① 研發(fā)環(huán)境

• 公司需要不斷為企業(yè)研發(fā)人員配備合適的本地研發(fā)工具（如多核高內(nèi)存的計(jì)算機(jī)設(shè)備、Mac 筆記本電腦），這些設(shè)備可能價(jià)值不菲，而且需要定期的更新?lián)Q代。
• 新加入的員工，在正式開(kāi)始開(kāi)發(fā)前，需要配置復(fù)雜的本地開(kāi)發(fā)環(huán)境，安裝特定的軟件及插件，并熟悉項(xiàng)目的研發(fā)流程及各個(gè)線上系統(tǒng)；部分項(xiàng)目因?yàn)榫W(wǎng)絡(luò)配置等問(wèn)題，可能第一時(shí)間無(wú)法在本地啟動(dòng)，還會(huì)耽誤不少額外的配置及調(diào)試時(shí)間。
• 公司需要投入較多的資源，才能構(gòu)建起匹配管理者需求的效能度量系統(tǒng)和安全管控系統(tǒng)，并且因?yàn)樵贫梭w系天生對(duì)開(kāi)發(fā)者本地環(huán)境的弱管控性，效果只能差強(qiáng)人意。
• 當(dāng)產(chǎn)品對(duì)保密性要求極高，或者當(dāng)企業(yè)外部成員參與對(duì)代碼保密性有要求的項(xiàng)目時(shí)，需要確保核心代碼的安全管控。

由此可見(jiàn)，本地開(kāi)發(fā)環(huán)境已逐步難適應(yīng)因公司規(guī)模擴(kuò)大所帶來(lái)的問(wèn)題，云端開(kāi)發(fā)工具（WebIDE）應(yīng)運(yùn)而生。盡管云端開(kāi)發(fā)工具有優(yōu)勢(shì)也有劣勢(shì)，不同的人對(duì)它所持的態(tài)度也不同，但云端開(kāi)發(fā)已是不可阻擋的趨勢(shì)。

② 代碼倉(cāng)庫(kù)

在研發(fā)的過(guò)程中，經(jīng)常會(huì)使用到代碼倉(cāng)庫(kù)。代碼倉(cāng)庫(kù)的開(kāi)發(fā)流程通常為：開(kāi)發(fā)人員下載代碼?創(chuàng)建工作分支?提交代碼?創(chuàng)建合作請(qǐng)求?邀請(qǐng)團(tuán)隊(duì)成員?參與代碼評(píng)審?倉(cāng)庫(kù)管理員審視后合入代碼。

開(kāi)源的代碼倉(cāng)庫(kù)通常應(yīng)用架構(gòu)集中，一旦待機(jī)則全部應(yīng)用不可用。除此之外，開(kāi)源代碼倉(cāng)庫(kù)只能使用共享文件系統(tǒng)支撐，如需擴(kuò)展得采用nfs，ceph等方案。不僅風(fēng)險(xiǎn)高，擴(kuò)展性能也低，對(duì)硬件的要求也高。

③ 代碼管理

為什么做要做靜態(tài)代碼檢查？因?yàn)榇a交付過(guò)程常見(jiàn)的問(wèn)題和風(fēng)險(xiǎn)有很多，比如：

• 重復(fù)代碼過(guò)多，造成開(kāi)發(fā)人力的浪費(fèi)以及后期維護(hù)成本增加
• 編碼風(fēng)格糟糕，代碼凌亂、不可讀，難于維護(hù)與開(kāi)發(fā)修改
• 圈復(fù)雜度過(guò)高，造成代碼可維護(hù)性、可繼承性降低，問(wèn)題定位難度加大
• 編碼安全風(fēng)險(xiǎn)，使用具有安全風(fēng)險(xiǎn)的函數(shù)，導(dǎo)致系統(tǒng)的安全性層級(jí)降低，加大系統(tǒng)的安全風(fēng)險(xiǎn)

那么，需要檢查代碼的什么方面呢？以下列舉幾種常見(jiàn)的代碼靜態(tài)檢查關(guān)注點(diǎn)：

A：重復(fù)率：表示一段源代碼在一個(gè)程序，或者一個(gè)團(tuán)體所維護(hù)的不同程序中重復(fù)出現(xiàn)

B：代碼風(fēng)格：程序開(kāi)發(fā)人員所編寫源代碼的書寫風(fēng)格，良好代碼風(fēng)格的特點(diǎn)是使代碼易讀

C：圈復(fù)雜度：衡量一個(gè)模塊判定結(jié)構(gòu)的復(fù)雜程度，數(shù)量上表現(xiàn)為獨(dú)立線性路徑條數(shù)，圈復(fù)雜度大說(shuō)明程序代碼可能質(zhì)量低且難于測(cè)試和維護(hù)

D：代碼安全：編碼過(guò)程中，常見(jiàn)的安全問(wèn)題包括（但不限于）：緩沖區(qū)溢出/跨站腳本攻擊(XSS)/SQL注入/XML 注入/LDAP 注入

藍(lán)鯨DevOps平臺(tái)代碼掃描工具CCheck當(dāng)下所具備的能力項(xiàng)，不僅內(nèi)置了檢查規(guī)則，并對(duì)相關(guān)規(guī)則做了簡(jiǎn)化，便于團(tuán)隊(duì)人員使用，能夠在較短的時(shí)間內(nèi)逐步提高代碼質(zhì)量。

④ 測(cè)試場(chǎng)景

在測(cè)試領(lǐng)域，一直爭(zhēng)論不休的話題有：關(guān)于單元測(cè)試到底是由開(kāi)發(fā)人員來(lái)做還是測(cè)試人員來(lái)做？針對(duì)當(dāng)下常用的微服務(wù)架構(gòu)，契約測(cè)試和Mock測(cè)試又該如何去做？以及如果有在線測(cè)試系統(tǒng)的話，又該如何把在線測(cè)試系統(tǒng)與本地的測(cè)試工具做聯(lián)動(dòng)？

盡管微服務(wù)架構(gòu)已十分普遍，但其存在著的分布式、最終一致性和管理復(fù)雜性等特性，也讓過(guò)去的測(cè)試?yán)砟罴肮ぞ呗杂行笆譄o(wú)策”。微服務(wù)是一種架構(gòu)風(fēng)格，它將單個(gè)的應(yīng)用設(shè)計(jì)成一組服務(wù)的集合。微服務(wù)架構(gòu)由于自身的高度模塊化、可獨(dú)立部署和技術(shù)多樣性優(yōu)勢(shì)，在當(dāng)前開(kāi)發(fā)系統(tǒng)或業(yè)務(wù)系統(tǒng)廣泛應(yīng)用。

PS. 契約測(cè)試和Mock測(cè)試

微服務(wù)架構(gòu)下，當(dāng)一個(gè)服務(wù)已經(jīng)同時(shí)被多個(gè)使用者調(diào)用的時(shí)候，怎么保證整體服務(wù)不會(huì)對(duì)其他使用者造成影響呢？契約測(cè)試，能很好的避免這類問(wèn)題。

契約測(cè)試定義了一套數(shù)據(jù)標(biāo)準(zhǔn)，既包含了請(qǐng)求也包含返回的數(shù)據(jù)項(xiàng)，通過(guò)對(duì)這些數(shù)據(jù)項(xiàng)事先做好了相關(guān)的定義，無(wú)論是消費(fèi)方還是生產(chǎn)者，只要遵循了契約測(cè)試的內(nèi)容，就可以保證服務(wù)實(shí)時(shí)暢通的進(jìn)行調(diào)用。契約測(cè)試通過(guò)驗(yàn)證Provider（生產(chǎn)者）是否按照期望的方式與Consumer（消費(fèi)方）進(jìn)行交互。

以下圖為例，假設(shè)現(xiàn)在不同的服務(wù)提供方對(duì)同一個(gè)請(qǐng)求提供了不同的數(shù)據(jù)形式，這三個(gè)服務(wù)都有"id"。但第二種微服務(wù)比第一種微服務(wù)多了"age"字段，而第三個(gè)微服務(wù)和第一個(gè)微服務(wù)相比，雖然都包含"name"字段，但"name"字段里的數(shù)據(jù)是不一樣的。此時(shí)如果是用接口測(cè)試來(lái)做的話，需要提供3個(gè)不同的請(qǐng)求來(lái)測(cè)試；但如果用契約測(cè)試來(lái)做的話，契約測(cè)試就相當(dāng)于是這三個(gè)的全集，只需要定義一種契約即可。

下圖是藍(lán)鯨DevOps平臺(tái)提供的測(cè)試工具CTest產(chǎn)品功能架構(gòu)圖，從中可以看出無(wú)論是對(duì)于支撐不同的測(cè)試模式，還是測(cè)試報(bào)告應(yīng)該具備的功能項(xiàng)，都已經(jīng)有了相關(guān)的能力，是個(gè)較為成熟的產(chǎn)品。在微服務(wù)測(cè)試時(shí)，想要實(shí)現(xiàn)環(huán)境無(wú)依賴，服務(wù)間無(wú)依賴？或者想要實(shí)現(xiàn)快速測(cè)試，支撐服務(wù)快速上線？這些都可以通過(guò)Mock測(cè)試來(lái)搞定，它就是在測(cè)試過(guò)程中，對(duì)于某些不容易構(gòu)造或者不容易獲取的對(duì)象，用一個(gè)虛擬的對(duì)象來(lái)創(chuàng)建以便測(cè)試的測(cè)試方法。

⑤ 編譯構(gòu)建

編譯構(gòu)建是指把軟件的源代碼編譯成目標(biāo)文件，并把配置文件和資源文件等打包的過(guò)程。

當(dāng)前，業(yè)界最流行的編程語(yǔ)言還是Java，不同的編程語(yǔ)言都有不同的構(gòu)建工具。對(duì)于流水線上的構(gòu)建工具來(lái)講，到底一款工具能支撐多少語(yǔ)言類型，也能考驗(yàn)一款編譯構(gòu)建工具的能力。

藍(lán)鯨DevOps流水線效能實(shí)踐工具，可以通過(guò)拖拽的形式構(gòu)建流水線，不像一些開(kāi)源工具，必須要會(huì)寫腳本和手工配置。而藍(lán)鯨DevOps流水線效能實(shí)踐工具，已經(jīng)把上述模塊和組件內(nèi)置了，降低了使用難度。

⑥ 軟件制品

軟件研發(fā)過(guò)程中的“源碼”和“軟件制品包”（通常被通俗稱為“二進(jìn)制包”）都是很關(guān)鍵的資產(chǎn)。軟件制品包通常是源碼文件的集合或者編譯后的產(chǎn)物，因此主要有二進(jìn)制包和壓縮包兩種形式，軟件制品包的管理和復(fù)用在發(fā)布管理有著關(guān)鍵的作用。

不同的編程語(yǔ)言，同樣會(huì)對(duì)應(yīng)不同的制品形式。現(xiàn)在之所以容器特別流行，就是因?yàn)樗帘瘟苏Z(yǔ)言帶來(lái)的限制，將包打成統(tǒng)一的格式，放到集群里邊進(jìn)行部署。

本地倉(cāng)庫(kù)是指開(kāi)發(fā)者個(gè)人PC中包文件的存儲(chǔ)包文件通常不放在源碼庫(kù)中管理，而是使用專門的包文件倉(cāng)庫(kù)進(jìn)行存儲(chǔ)并配合包文件依賴管理工具（Maven、NPM、Ivy等）進(jìn)行使用。包文件倉(cāng)庫(kù)可以大致分為本地倉(cāng)庫(kù)、私服倉(cāng)庫(kù)、中央倉(cāng)庫(kù)三種。

• 私服倉(cāng)庫(kù)通常是企業(yè)為了提升包文件使用性能搭建的局域網(wǎng)內(nèi)共用的包文件倉(cāng)庫(kù)，通常使用開(kāi)源的Nexus、Artifactory等工具搭建
• 中央倉(cāng)庫(kù)是指開(kāi)源包文件的共享社區(qū)

私服倉(cāng)庫(kù)把源碼倉(cāng)庫(kù)拉下來(lái)，通過(guò)持續(xù)構(gòu)成的工具打包并存在私服倉(cāng)庫(kù)中。對(duì)依賴管理這塊，比如項(xiàng)目和工程依賴一些開(kāi)源的相關(guān)組件，那么私服就會(huì)把這些開(kāi)源組件從互聯(lián)網(wǎng)中央倉(cāng)庫(kù)拉下來(lái)，放到私服倉(cāng)庫(kù)上。開(kāi)發(fā)人員在內(nèi)網(wǎng)就可以根據(jù)需要，拉取代碼或依賴包在本地做功能開(kāi)發(fā)，做完后再提交到源碼庫(kù)，最終打成二進(jìn)制介質(zhì)放到私有倉(cāng)庫(kù)里。

PS. 什么是軟件制品庫(kù)？

軟件制品庫(kù)指能夠統(tǒng)一管理各種類型的二進(jìn)制制品，同時(shí)無(wú)縫對(duì)接現(xiàn)有的標(biāo)準(zhǔn)化構(gòu)建和發(fā)布工具的軟件平臺(tái)。也就說(shuō)制品庫(kù)既能夠存儲(chǔ)中間產(chǎn)物，也能存儲(chǔ)結(jié)果產(chǎn)物。“軟件包”及其屬性的管理是發(fā)布過(guò)程管理的基礎(chǔ)，也是軟件開(kāi)發(fā)過(guò)程中的重要資產(chǎn)。

軟件制品庫(kù)在DevOps工具鏈中的開(kāi)發(fā)集成、測(cè)試、生產(chǎn)等階段都有作用，相關(guān)人員可在不同階段把制品打完后放到制品庫(kù)。一旦流程走到下一個(gè)環(huán)節(jié)，比如走到開(kāi)發(fā)、測(cè)試，走到整個(gè)上線管理，制品也會(huì)做相應(yīng)的晉級(jí)。

作為DevOps的重要樞紐，如果沒(méi)有統(tǒng)一可信制品庫(kù)，DevOps和CI/CD運(yùn)轉(zhuǎn)起來(lái)，就像流水線沒(méi)了軸承，研發(fā)規(guī)模越大，問(wèn)題和隱患就越多。雖然源碼都是同一套，但是開(kāi)發(fā)環(huán)境和測(cè)試環(huán)境的不同，會(huì)導(dǎo)致代碼運(yùn)行不起來(lái)。但如果能夠保證在不同的環(huán)境下，用的都是同一個(gè)制品，那就能盡量少的屏蔽環(huán)境不同帶來(lái)的影響。

比如經(jīng)常聽(tīng)到“誒這個(gè)代碼在我這里運(yùn)行可以啊，怎么在你哪里運(yùn)行不了？那肯定是你本地服務(wù)器的毛病。”因此，通過(guò)制品庫(kù)的使用，能逐步避免這類現(xiàn)象的產(chǎn)生。

該客戶是內(nèi)外網(wǎng)隔離的，私服負(fù)責(zé)從外網(wǎng)的中央倉(cāng)庫(kù)下載依賴包，內(nèi)網(wǎng)的依賴庫(kù)和外網(wǎng)的私服庫(kù)進(jìn)行打通，以便于數(shù)據(jù)同步。所有內(nèi)網(wǎng)的研發(fā)團(tuán)隊(duì)，都是從依賴庫(kù)下載所需資源包，并做一些安全掃描等管理工作。由于該團(tuán)隊(duì)是分布式的開(kāi)發(fā)團(tuán)隊(duì)，在全國(guó)各地都有相應(yīng)的團(tuán)隊(duì)，每個(gè)城市都有自己的制品倉(cāng)庫(kù)作為本地的倉(cāng)庫(kù)節(jié)點(diǎn)，在開(kāi)發(fā)中心有一個(gè)主節(jié)點(diǎn)，這樣就把制品庫(kù)做了一個(gè)主從的模式，以便制品的同步和晉級(jí)。

03. DevOps實(shí)現(xiàn)自動(dòng)化部署

自動(dòng)化部署可以減少人肉運(yùn)維和手工運(yùn)維的工作量，也能盡量避免人工操作所帶來(lái)的的錯(cuò)誤和風(fēng)險(xiǎn)。自動(dòng)化部署是指將可交付產(chǎn)品，快速且安全地交付用戶使用的一套系統(tǒng)和工具。系統(tǒng)會(huì)自動(dòng)構(gòu)建、測(cè)試并準(zhǔn)備代碼變更，以便將其發(fā)布到指定環(huán)境的過(guò)程，包括開(kāi)發(fā)環(huán)境、預(yù)發(fā)布環(huán)境、生產(chǎn)環(huán)境等。

系統(tǒng)模板是自動(dòng)化部署服務(wù)的關(guān)鍵特性。通過(guò)使用系統(tǒng)模板快速創(chuàng)建部署任務(wù)，然后將組合的部署步驟保存為自定義模板，這樣在下一次部署任務(wù)來(lái)臨時(shí)，就可以直接使用該模板。

我們把不同系統(tǒng)的發(fā)布策略做了一個(gè)整理匯總（見(jiàn)下圖），如果實(shí)際應(yīng)用場(chǎng)景具備這些能力項(xiàng)，就可以跟其他的組件相結(jié)合，對(duì)外提供不同的發(fā)布策略。

04. 企業(yè)文化推廣

有了前面的方法論，又該怎么開(kāi)始準(zhǔn)備和實(shí)施呢？

準(zhǔn)備階段1：選擇合適的試點(diǎn)項(xiàng)目

從最有同理心和最樂(lè)于創(chuàng)新的團(tuán)隊(duì)開(kāi)始，擴(kuò)大DevOps的范圍。在逐步擴(kuò)大的過(guò)程中，發(fā)現(xiàn)創(chuàng)新者和早期采用者，贏得沉默的大多數(shù)，并識(shí)別意愿較低的“釘子戶”。最后，盡早展示成果并積極宣傳，將大目標(biāo)分解成漸進(jìn)式的小步驟。

Tips: 改進(jìn)試點(diǎn)項(xiàng)目時(shí)，不但要努力降低復(fù)雜性，提高可靠性和穩(wěn)定性，而且還應(yīng)該更快、更安全、更容易變更，團(tuán)隊(duì)才可能更愿意嘗試。

準(zhǔn)備階段2：組建全功能團(tuán)隊(duì)

軟件開(kāi)發(fā)團(tuán)隊(duì)的結(jié)構(gòu)對(duì)軟件產(chǎn)品的架構(gòu)和成果有巨大的影響，利用康威定律組織團(tuán)隊(duì)，減少工作交接次數(shù)，提升交付速度和成功率。小團(tuán)隊(duì)獨(dú)立運(yùn)作，彼此充分解耦，避免過(guò)多的溝通與協(xié)調(diào)。牢記兩個(gè)比薩原則，保持小規(guī)模。

準(zhǔn)備階段3：團(tuán)隊(duì)成熟度評(píng)估

在對(duì)團(tuán)隊(duì)進(jìn)行成熟度評(píng)估時(shí)，可從價(jià)值、能力、角色三個(gè)方面進(jìn)行考慮，參考業(yè)界端新型的研發(fā)能力框架對(duì)團(tuán)隊(duì)進(jìn)行成熟度評(píng)估。

準(zhǔn)備階段4：價(jià)值流分析實(shí)例

• 召集所有關(guān)鍵成員，繪制價(jià)值流圖。
• 記錄主要的步驟和細(xì)節(jié)，讓相關(guān)干系人員擁有同樣的視圖。
• 重點(diǎn)分析和優(yōu)化，識(shí)別阻礙：需要等待數(shù)周甚至數(shù)月的工作；引發(fā)或處理重大返工的工作。
• 確定想要改進(jìn)的度量指標(biāo)，通過(guò)探索各種假設(shè)，然后分析結(jié)果，不斷迭代和重復(fù)，將獲得的經(jīng)驗(yàn)用于下一次實(shí)驗(yàn)。

團(tuán)隊(duì)敏捷：敏捷意識(shí)強(qiáng)化、知識(shí)點(diǎn)與工具使用培訓(xùn)、敏捷會(huì)議的觀察及引導(dǎo)、測(cè)試前移、團(tuán)隊(duì)質(zhì)量監(jiān)控、SoS敏捷管理方法在實(shí)施階段，確定實(shí)施的優(yōu)先級(jí)，按優(yōu)先級(jí)逐一推進(jìn)。

• 業(yè)務(wù)敏捷：探求運(yùn)用用戶故事地圖、實(shí)例化需求與用戶故事、進(jìn)行需求條目化、利用需求條目需求及任務(wù)分拆、形成統(tǒng)一的產(chǎn)品需求列表、探求估算與與迭代計(jì)劃、探求需求溝通與反饋方式
• 工程敏捷：自動(dòng)化單元測(cè)試、自動(dòng)化代碼掃描、自動(dòng)化集成測(cè)試、自動(dòng)化功能/流程測(cè)試、持續(xù)集成、持續(xù)交付、部署流水線、主干開(kāi)發(fā)
• 管理工具：電子看板/物理看板、任務(wù)列表、項(xiàng)目狀態(tài) - 燃盡圖、增值流圖

DevOps是數(shù)字化轉(zhuǎn)型成功的關(guān)鍵之一，雖然DevOps建設(shè)非一日之功，但是建成之后的價(jià)值不只能提升企業(yè)IT研發(fā)效能、交付質(zhì)量和靈活應(yīng)對(duì)業(yè)務(wù)需求的變化，對(duì)提升企業(yè)內(nèi)部團(tuán)隊(duì)的協(xié)作和敏捷能力都有著顯著變化。