分享人：鄭云龍

時(shí)間：2016–8–25

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

 

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

 

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

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

持續(xù)支付

 

 

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

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

全功能團(tuán)隊(duì)

 

 

 

 

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

 

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

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

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

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

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

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

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

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

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

• 提交階段

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

• 自動(dòng)化驗(yàn)收測試階段

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

• 手動(dòng)測試階段

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

• 發(fā)布階段

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

 

原則二：將幾乎所有事情自動(dòng)化

 

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

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

• 自動(dòng)化構(gòu)建

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

• 自動(dòng)化測試

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

• 基礎(chǔ)設(shè)施及代碼

在虛擬化技術(shù)和容器化技術(shù)盛行的今天，通過諸如AWS的CloudFormation以及Docker的Dockerfile等我們可以將我們的基礎(chǔ)設(shè)施也變成自動(dòng)化的

另一方面則涉及到與軟件運(yùn)行相關(guān)的自動(dòng)化如包括基礎(chǔ)設(shè)施的自動(dòng)化管理，運(yùn)行環(huán)境的自動(dòng)化配置，軟件本身的安裝與配置等等

• 自動(dòng)化配置管理

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

 

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

 

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

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

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

 

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

 

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

 

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

 

在持續(xù)交付過程中持續(xù)交付流水線定義了一套標(biāo)準(zhǔn)的，可重復(fù)的軟件交付流程；同時(shí)借助大量的工具我們可以將這個(gè)流程中的機(jī)會(huì)所有事情都進(jìn)行自動(dòng)化。但是另外一個(gè)點(diǎn)就是軟件質(zhì)量。

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

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

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

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

 

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

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

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

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

 

原則七：交付過程是每個(gè)成員的責(zé)任

 

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

而在持續(xù)交付當(dāng)中我們知道，對于交付團(tuán)隊(duì)而言最終目標(biāo)是確保軟件能夠交付到用戶手中，并且產(chǎn)生相應(yīng)的價(jià)值。

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

 

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

 

在任何一個(gè)充滿生機(jī)的組織當(dāng)中持續(xù)改進(jìn)是這個(gè)組織保持活力的基本要素之一。

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

 

 

為了持續(xù)交付組織應(yīng)該做好哪些準(zhǔn)備？

 

 

交付團(tuán)隊(duì)而非部門

 

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

由于存在部門墻的存在，導(dǎo)致開發(fā)，測試，運(yùn)維之間的大量溝通成本，嚴(yán)重影響效率。甚至嚴(yán)重時(shí)部門和部門之間甚至?xí)浅Ｈ菀灼饹_突。

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

而通過“交付團(tuán)隊(duì)”從項(xiàng)目一開始讓所有項(xiàng)目成員能夠參與到軟件的交付過程中，確保各個(gè)角色的人員能夠頻繁的進(jìn)行交流，并且為了一致的目標(biāo)而共同努力，這也是DevOps運(yùn)動(dòng)核心價(jià)值

而相同角色之間的溝通交流通過社團(tuán)COP的形式來進(jìn)行領(lǐng)域知識(shí)的交流和提升是一個(gè)不錯(cuò)的方式

 

 

充分授權(quán)團(tuán)隊(duì)

 

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

 

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

 

 

平臺(tái)化，服務(wù)化

 

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

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

• 基礎(chǔ)設(shè)施自服務(wù)

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

• 平臺(tái)化服務(wù)

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