分享人：鄭云龍

時間：2016–8–25

睿云智合持續(xù)交付產(chǎn)品負責人，在敏捷和DevOps領域有豐富經(jīng)驗的實踐，過去作為敏捷和DevOps技術教練向多家大型企業(yè)提供咨詢和培訓服務。

 

持續(xù)交付理論要解決的最重要的問題就是，如何以最快的方式將我們的軟件交付到客戶手上；如何實現(xiàn)可靠，迅速并且低風險的軟件發(fā)布。

 

在傳統(tǒng)的軟件開發(fā)方法中我們更多的關注軟件研發(fā)環(huán)節(jié)，而DevOps運動則將軟件研發(fā)活動的視角從傳統(tǒng)的需求，開發(fā)，測試等活動延伸到了部署，發(fā)布以及運維過程中。

軟件的核心價值是為軟件的使用者帶來收益，在過去我們經(jīng)常聽到開發(fā)人員說這個功能已經(jīng)開發(fā)完成了。?但是在持續(xù)交付中我們認為之后將特性真正的發(fā)布到用戶手上才以為則完成。

持續(xù)支付

 

 

而要想達到持續(xù)交付的目標即實現(xiàn)可靠，迅速并且低風險的軟件交付需要所有相關人員（需求，開發(fā)，測試，運維）的協(xié)同工作才能保證這一目標的實現(xiàn)。

在持續(xù)交付過程中我們希望一個團隊是能夠充分自治的，能夠完成從軟件的需求，設計，開發(fā)，部署以及運維的端到端所有工作。

全功能團隊

 

 

 

 

本文將以持續(xù)交付的8個原則來闡述在持續(xù)交付過程中的那些方法和實踐：

 

原則一：為軟件的發(fā)布創(chuàng)建一個可重復且可靠的過程

在傳統(tǒng)的軟件研發(fā)模式中瀑布式的工作方式深入到軟件研發(fā)的各個環(huán)境。

在軟件的發(fā)布過程中充滿了各種等待：

• 構建和運維人員在等待說明文檔或者缺陷修復
• 測試人員等待“好的”版本構建出來
• 研發(fā)團隊可能在新功能發(fā)布幾周后才收到缺陷報告

最終的結果就是軟件產(chǎn)品遲遲不能發(fā)布甚至延期，同時由于開發(fā)與測試，開發(fā)和運維之間的過長的反饋周期直接導致軟件產(chǎn)品的質(zhì)量低下，同時可能并不能真正的為使用者帶來價值

同時如果管理者想要對整個軟件交付過程進行改善將會很容易陷入到局部優(yōu)化的惡性循環(huán)當中，很難真正了解交付的問題瓶頸

而持續(xù)部署流水線則是解決這一問題的最佳方式，建立持續(xù)部署流水線即建立了一套端到端的軟件交付流程，同時在持續(xù)部署流水線的流程當中參與到軟件交付的各個角色都能各司其職，形成一套高效的“拉動系統(tǒng)”

開發(fā)人員持續(xù)的查看代碼度量數(shù)據(jù)以及測試失敗等問題，測試人員自助部署測試環(huán)境，同時運維人員也可以通過一鍵方式將軟件部署到預生產(chǎn)環(huán)境以及生產(chǎn)環(huán)境。同時對于管理人員也可以通過度量持續(xù)部署流水線的各個環(huán)境來分析交付問題，通過合理的方式優(yōu)化軟件交付流程當中存在的問題。

而將持續(xù)部署流水線中的各個環(huán)節(jié)可以劃分為如下幾個不同的階段

• 提交階段

該階段主要從技術層面證明軟件系統(tǒng)是可以工作的，該階段會進行軟件的編譯，以及以單元測試為主的自動化測試，以及代碼分析

• 自動化驗收測試階段

該階段主要從功能和非功能需求角度正面軟件是能夠滿足用戶的需求以及相關的需求驗收條件

• 手動測試階段

該階段主要試圖發(fā)現(xiàn)那些自動化驗收測試不能覆蓋的缺陷，同時證明系統(tǒng)是否能夠真正的為用戶提供價值，所以在該階段中通常需要由測試人員完成相關的探索性測試，集成測試以及用戶驗收測試

• 發(fā)布階段

發(fā)布階段則旨在將軟件產(chǎn)品發(fā)布到用戶手中包括軟件包發(fā)布或者是直接將軟件部署到生產(chǎn)環(huán)境

 

原則二：將幾乎所有事情自動化

 

為了搞笑的支持持續(xù)部署流水線，我們需要將除了探索性測試以外幾乎所有的事情都自動化。

在軟件交付過程中對于自動化我們可以分為兩個方面，一方面是指在產(chǎn)生軟件包過程中的如：編譯，打包，單元測試，集成測試，自動化驗收測試等活動。

• 自動化構建

在這個過程中我們使用例如maven,gradle這樣的構建工具可以幫助自動化的完成軟件的構建以及解決軟件依賴問題

• 自動化測試

同時借助諸如robotframework,以及cucumber這樣的自動化測試工具，以及采用BDD或者ATDD的開發(fā)實踐能夠幫助我們產(chǎn)生高質(zhì)量的自動化驗收測試集

• 基礎設施及代碼

在虛擬化技術和容器化技術盛行的今天，通過諸如AWS的CloudFormation以及Docker的Dockerfile等我們可以將我們的基礎設施也變成自動化的

另一方面則涉及到與軟件運行相關的自動化如包括基礎設施的自動化管理，運行環(huán)境的自動化配置，軟件本身的安裝與配置等等

• 自動化配置管理

自動化配置管理工具如ansible,puppet,chef等相比傳統(tǒng)的腳本。通過dsl環(huán)境描述的過程將服務器環(huán)境的準備過程變成自動化的，可重復的，并且能夠支持大規(guī)模的集群管理

 

原則三：把所有東西納入版本控制

 

在過去通常而言我們的svn或者git當中只存在我們源代碼本身，而在持續(xù)交付過程當中我們認為任何會對軟件的行為，質(zhì)量產(chǎn)生影響的部分都應該要做版本化的，并且這些任何部分的每一次變更都應該通過持續(xù)部署流水線的形式來進行自動化的驗證。確保任何的變更，如代碼變更，測試用例變更，環(huán)境配置變更都能得到快速的驗證，以及反饋

這些相關的“變更集”包括：基礎設施描述文件,源代碼，測試腳本，自動化測試用例，環(huán)境配置腳本，部署腳本，以及數(shù)據(jù)庫的創(chuàng)建，升級，以及回滾腳本等。

從上面的“變更集”也可以看出，持續(xù)交付是一個團隊所有人員和角色都應該參與的事情，并且每一個人都對軟件交付富有責任

 

原則四：提前并頻繁的做讓你感到痛苦的事情

 

“如果集成是讓你感到痛苦的，那么每一次代碼提交都應該進行集成，而且應該從項目一開始就開始這么做；如果發(fā)布軟件過程前測試是一件痛苦的事情，那么就應該從項目一開始就不斷的進行測試；如果軟件發(fā)布是一件痛苦的事情，那么每一次代碼提交在完成自動化驗收測試之后都應該進行發(fā)布，或者至少發(fā)布到類生產(chǎn)環(huán)境”

 

原則五：內(nèi)建質(zhì)量

 

在持續(xù)交付過程中持續(xù)交付流水線定義了一套標準的，可重復的軟件交付流程；同時借助大量的工具我們可以將這個流程中的機會所有事情都進行自動化。但是另外一個點就是軟件質(zhì)量。

根據(jù)原則四，其實我們也可以推斷出如果對代碼進行測試是一件痛苦的事情，那么在編寫實現(xiàn)代碼之前我們就應該寫測試，TDD，ATDD，BDD等軟件研發(fā)實踐正是體現(xiàn)了這一基本原則。

內(nèi)建質(zhì)量是戴明提出的名言之一。越早的發(fā)現(xiàn)缺陷，修復它們的成本越低。

根據(jù)內(nèi)建質(zhì)量的原則我們可以知道在軟件交付過程中，測試并不是一個階段，所以并不應該在開發(fā)介紹之后才開始。同時測試也不應該主要是測試人員的職責，參與交付的所有人都應該對軟件的質(zhì)量負責

其中測試四象限很好的闡述了為了確保軟件質(zhì)量而應該做的各種類型的測試建模

 

原則六：“Done”意味著“已發(fā)布”

在持續(xù)交付過程中認為一個特性的交付在理想狀態(tài)下應該是已經(jīng)發(fā)布到用戶手中，或者至少已經(jīng)向用戶進行了演示。

相應的在敏捷開發(fā)中，我們每一個迭代結束后都應該想”用戶代表”進行演示，并且在“用戶代表”試用認為是完成了之后才意味則“Done”

其中“用戶代表”可以是正在的用戶，也可以是相關的業(yè)務人員

 

原則七：交付過程是每個成員的責任

 

在現(xiàn)實情況下，測試部門總是抱怨研發(fā)交付的軟件質(zhì)量差，運維總是抱怨軟件不夠穩(wěn)定，開發(fā)總是抱怨缺陷反饋周期太長，解決問題的成本過高。

而在持續(xù)交付當中我們知道，對于交付團隊而言最終目標是確保軟件能夠交付到用戶手中，并且產(chǎn)生相應的價值。

而通過持續(xù)部署流水線，我們將所有參與到軟件交付中的角色都聯(lián)合成了一個整體，并且各個部分之間是能夠快速的產(chǎn)生反饋，促成各個成員和角色之間的交流，并且快速的解決問題

 

原則八：持續(xù)改進

 

在任何一個充滿生機的組織當中持續(xù)改進是這個組織保持活力的基本要素之一。

參與軟件交付的成員需要定期對過去一段時間內(nèi)的交付工作進行回顧，去發(fā)現(xiàn)在這個流程當中的做的好的方面，以及做的不好的方面，并且提出解決方案。

 

 

為了持續(xù)交付組織應該做好哪些準備？

 

 

交付團隊而非部門

 

根據(jù)康威定律“設計系統(tǒng)的組織，其產(chǎn)生的設計和架構等價于組織間的溝通結構”

由于存在部門墻的存在，導致開發(fā)，測試，運維之間的大量溝通成本，嚴重影響效率。甚至嚴重時部門和部門之間甚至會非常容易起沖突。

開發(fā)人員只管完成既定的功能缺乏系統(tǒng)整體性思考；測試人員根據(jù)需求文檔完成測試用例，但是卻不思考需求本身的合理性；運維人員則缺少對軟件架構本身的理解。各個部門看似各司其職進井有條，但是卻很難對軟件交付的效率和質(zhì)量做出太多實質(zhì)性的貢獻。正如開篇所述，

而通過“交付團隊”從項目一開始讓所有項目成員能夠參與到軟件的交付過程中，確保各個角色的人員能夠頻繁的進行交流，并且為了一致的目標而共同努力，這也是DevOps運動核心價值

而相同角色之間的溝通交流通過社團COP的形式來進行領域知識的交流和提升是一個不錯的方式

 

 

充分授權團隊

 

確保持續(xù)交付實踐的成功，賦能團隊，授權團隊也是整個組織應該思考的問題。在持續(xù)交付中我們知道一個團隊是一個應該是以做產(chǎn)品而非做項目為目標，需要充分授權團隊，使得團隊能夠完成從需求，開發(fā)，測試，上線的端到端過程。

 

當然在實際情況中，組織會有更多的因素需要考慮，比如最典型的場景比如由于落后的基礎設施管理方式導致運維團隊往往是被動的響應研發(fā)團隊的需求，并且存在大量手動的操作環(huán)節(jié)導致時間和資源的浪費

 

 

平臺化，服務化

 

• 公有云，私有云，容器云

通過組織級別引入虛擬化或者容器化技術以及相應的管理平臺如OpenStack,Rancher,Ks8等工具可以大大減少Ops團隊的運維團隊，在過去需要大量手工操作的過程都可以通過虛擬化平臺或者容器化平臺完成，研發(fā)團隊或者資源的周期從之前的幾天縮短到幾分鐘。

• 基礎設施自服務

同時對于Ops團隊則專注于提供底層的基礎設施資源，包括網(wǎng)絡，安全等相關管理。并將相關的資源以服務的形式暴露給團隊，各個產(chǎn)品團隊管理自己的基礎設施環(huán)境，維護持續(xù)部署流水線，以及軟件運行環(huán)境的變更

• 平臺化服務

同時對于企業(yè)和組織而言通過引入統(tǒng)一的平臺化服務，可以完成對所有產(chǎn)品團隊的統(tǒng)一管理，和監(jiān)控。這些關鍵的平臺化服務可能包括：統(tǒng)一的日志管理平臺，持續(xù)交付平臺，以及監(jiān)控和運營平臺等。