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

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

• 簡單的業(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é)合起來呢？

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

我們對標業(yè)界最佳實踐，爭做國內(nèi)最好的項目管理工具，不僅既支持瀑布開發(fā)模式，還支持敏捷開發(fā)模式；同時具備存儲文檔、Wiki等功能。也就是說，在項目管理和需求管理方面，我們的平臺能涵蓋95%以上的使用場景（掃描文末海報二維碼，立即申請試用）。軟件開發(fā)流程在這兒不過多介紹，業(yè)界用的最多的就是瀑布開發(fā)模式、敏捷開發(fā)模式和DevOps開發(fā)模式。盡管常見的開發(fā)模式是這些，但是大多數(shù)工具只支持敏捷開發(fā)模式，很少有工具支持雙態(tài)（既支持瀑布，又支持敏捷開發(fā)模式）模式。

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

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

隨著公司規(guī)模的擴大，開發(fā)層面常面臨以下問題：

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

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

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

② 代碼倉庫

在研發(fā)的過程中，經(jīng)常會使用到代碼倉庫。代碼倉庫的開發(fā)流程通常為：開發(fā)人員下載代碼?創(chuàng)建工作分支?提交代碼?創(chuàng)建合作請求?邀請團隊成員?參與代碼評審?倉庫管理員審視后合入代碼。

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

③ 代碼管理

為什么做要做靜態(tài)代碼檢查？因為代碼交付過程常見的問題和風(fēng)險有很多，比如：

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

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

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

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

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

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

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

④ 測試場景

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

盡管微服務(wù)架構(gòu)已十分普遍，但其存在著的分布式、最終一致性和管理復(fù)雜性等特性，也讓過去的測試理念及工具略有些“束手無策”。微服務(wù)是一種架構(gòu)風(fēng)格，它將單個的應(yīng)用設(shè)計成一組服務(wù)的集合。微服務(wù)架構(gòu)由于自身的高度模塊化、可獨立部署和技術(shù)多樣性優(yōu)勢，在當(dāng)前開發(fā)系統(tǒng)或業(yè)務(wù)系統(tǒng)廣泛應(yīng)用。

PS. 契約測試和Mock測試

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

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

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

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

⑤ 編譯構(gòu)建

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

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

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

⑥ 軟件制品

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

不同的編程語言，同樣會對應(yīng)不同的制品形式。現(xiàn)在之所以容器特別流行，就是因為它屏蔽了語言帶來的限制，將包打成統(tǒng)一的格式，放到集群里邊進行部署。

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

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

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

PS. 什么是軟件制品庫？

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

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

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

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

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

03. DevOps實現(xiàn)自動化部署

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

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

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

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

有了前面的方法論，又該怎么開始準備和實施呢？

準備階段1：選擇合適的試點項目

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

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

準備階段2：組建全功能團隊

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

準備階段3：團隊成熟度評估

在對團隊進行成熟度評估時，可從價值、能力、角色三個方面進行考慮，參考業(yè)界端新型的研發(fā)能力框架對團隊進行成熟度評估。

準備階段4：價值流分析實例

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

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

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

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