華為開發(fā)匯(Huawei Developers Gathering)簡稱“HDG”，旨在為廣大開發(fā)者分享華為內(nèi)部、合作伙伴以及社區(qū)成員的干貨，營造一個自由、開放、分享的技術(shù)交流平臺。是華為今年一個重要的技術(shù)交流活動，計劃將在全國各個地區(qū)舉辦。

9月，HDG成都站如期舉行，林帆是HDG成都站***一位發(fā)言的講師，他作為ThoughtWorks高級DevOps技術(shù)顧問，帶來的是《構(gòu)建企業(yè)級私有云持續(xù)交付平臺》的主題演講，講解了如何通過整合開源社區(qū)中的優(yōu)秀軟件，使其匹配企業(yè)級應(yīng)用的場景。其中涉及的一些方案細節(jié)等都是***次在外部活動中進行展示。

現(xiàn)場實錄如下：

我今天的話題主要有下面幾個部分，首先我想簡單過一下關(guān)于持續(xù)交付概念基本的價值，和它的主要內(nèi)容。然后再說一說在企業(yè)級的應(yīng)用當中能夠使用開源的工具，做這種交付的話，哪些事情是可以做的，哪些事情是具有缺陷的。***一點是想用一些開源的工具做一個全流程的持續(xù)交付平臺的話，我們應(yīng)該怎么去做。

持續(xù)交付的概念到現(xiàn)在也有五六年的歷史了，在座的多少都聽過持續(xù)交付這個概念吧，大家半數(shù)以上都聽過。持續(xù)交付，這本書是在2010年時候英文版就已經(jīng)出來了，國內(nèi)的中文版稍微晚一些。持續(xù)交付的想法是，我們始終將我們已經(jīng)開發(fā)好的工具保持在一個可交付、可上線的狀態(tài)上，當我們支持的人說這部分完成了，是沒問題的，可以立馬上線，這樣就以最快的速度來實現(xiàn)這部分的功能價值，并且在***時間把我們的軟件功能走到一個反饋，它是不是我們想要的。

到現(xiàn)在來說很多時候我們對軟件交付周期比較有要求的企業(yè)，特別是互聯(lián)網(wǎng)創(chuàng)業(yè)企業(yè)，對持續(xù)交付理念的追求度是比較高的。因為它一個主要的特點是，它從實踐層面上去提出一些工具和方法，能夠?qū)⑦@種快速迭代的方式實踐落地。這些方法包括我們更加頻繁的做交付，更加頻繁的做周期反饋，相關(guān)情況的具化，主要是關(guān)于自動化的工具。通過這些持續(xù)交付的工具能夠很好的幫助開發(fā)者，包括幫助團隊去實現(xiàn)更好的交付流程的自動化，交付流程的打通。當流通出問題的時候，能夠***時間把出問題的地方反饋出來，比如說代碼出問題了，提交了一個有問題的功能之后，***時間進行自動化設(shè)置，這樣可以最快的得到問題反饋，最快的把問題解決。

通過這種開源的工具，是不是能夠真正的幫企業(yè)解決所有這個過程中所需要解決的問題呢，答案是不一定，這個要看我們實際團隊的規(guī)模和我們團隊對持續(xù)交付概念的訴求。如果是對一個比較小的團隊來說的話，很多小團隊是一個互聯(lián)網(wǎng)團隊，基本的交付***的訴求就是我能夠多快的把這個軟件，通過一個穩(wěn)定可控的方式把它上線。因為對于這樣企業(yè)來說的話，軟件交付的速度不單單是軟件的價值回饋的速度，更重要的它直接決定了一個產(chǎn)品，甚至是一個公司生與死的問題。像這樣子的產(chǎn)品它主要幫助解決的是，我怎樣去構(gòu)建這樣一條可視化的通路，我把代碼編譯之后，***時間對代碼進行檢查，***時間進行反饋，沒有問題之后我會***時間把這個功能上線，給用戶使用，得到用戶的反饋。對于這種需求點的話，大部分的開源工具已經(jīng)能夠比較好的滿足小團隊、個人開發(fā)這樣的一些需求。

當我們把產(chǎn)品放到一個更大的團隊，對于一個企業(yè)級的用戶來說，企業(yè)級的用戶是比較大的，所以它的交付周期會比較長，它的交付團隊是跨團隊進行合作的。從任何一個點上都很難一眼看出所有團隊的交付狀況，在這種情況下我們需要很多的指標，來告訴我們這個項目當中的哪一個部門，哪一個部分的地方有問題。不像是我們很輕松的一眼望盡所有的上面有幾百個路線，幾百個項目，很大型的一個產(chǎn)品。這樣的話我們會需要對這個產(chǎn)品提出很多指標性的訴求，從上層往下看的時候能清楚的看到整個產(chǎn)品交付的狀態(tài)。這個指標就包括我們在代碼提交之后，可以看某個子項目上面代碼提交的頻率，代碼成功的比例，以及進行代碼掃描，進行測試的時候，測試的夠不夠。進行代碼掃描的時候，掃描出來的問題多不多。這些問題都可以反映出這個產(chǎn)品的質(zhì)量是否會延遲交付，是否會有一些問題。同樣的當我們把這個項目進行布置的時候，同樣也可以獲得很多，包括每個子產(chǎn)品部署的周期，這個子模塊或者這個子項目是否匹配，是否會存在一些潛在的問題。這些東西都需要通過一些指標性的東西才能提供出來。除此以外，除了指標還有一方面就是我們需要很多的實踐，就是更多的實踐的東西，去配合這些溝通合作。比如我們需要一些統(tǒng)一的分制策略，怎么去管理我們代碼的分解。怎么去通過一些文件的機制，去保證非常差的提交，不能夠進入正常的運行，在做測試的時候，一旦有其中一個模塊出現(xiàn)問題，會影響整個測試的結(jié)果。這個保證如果代碼掃描出現(xiàn)非常嚴重的問題的時候，這個提交整個會部署。部署打包的時候我們也需要通過一些實踐來保證它怎樣***進行自動化，并且是一個比較統(tǒng)一的自動化的關(guān)系，去完成整個產(chǎn)品的部署，這樣對于后續(xù)的運維和運營有比較大的收益。

所有這些事情不單單是一個單純的工具能夠解決的問題，可能需要一些國外的指標，國外的實踐，來保證我們大型企業(yè)項目的交付過程。包括后面從正常運營到延遲需求的回饋，這部分已經(jīng)超出了持續(xù)交付要解決的問題，但是我們確實也是從企業(yè)級交付的時候必須要做的一個部分。

剛剛提到的這些是說我們這些開源的持續(xù)交付工具，可能不能非常好的滿足企業(yè)級需求當中所需要的這么多，包括有指標性的，包括有實踐性的東西。

第二個問題是關(guān)于數(shù)據(jù)的集成，剛才說在企業(yè)的應(yīng)用當中我們更需要關(guān)注一些指標性的東西。因為對小團隊來說的話，可能我們***眼就能看到這個項目當中每一部分的狀態(tài)是什么樣的，是不是現(xiàn)在已經(jīng)部署過了，這個我們都能計算出來。但是對于大型項目的時候，我們可能需要一些額外的數(shù)據(jù)進行支撐，這些數(shù)據(jù)的整合，對于開元的工具來說也是沒有的。這些數(shù)據(jù)就包括過去的數(shù)據(jù)，包括我們做代碼測試，做產(chǎn)品測試時候的測試數(shù)據(jù)，包括我們對項目進行部署的時候會有一個部署周期，兩點要匹配模塊之間的部署的API的性能。假設(shè)我做了hos相關(guān)的，一般從1.0到2.0之后會升級，是否會存在問題，這些問題是通過數(shù)據(jù)可以暴露出來的。但是對于開源組建來說的話，它對數(shù)據(jù)這塊的集成是缺失的，這是第二個問題。

第三個問題，剛才說到對于小型團隊來說的話，它的關(guān)注點主要在于交付，我們把這個軟件開發(fā)出來之后，把代碼提交，我用自動化工具，把所有的東西進行測試，測試沒問題之后，把測試內(nèi)容看一下，沒問題就自動化的部署上線，這樣就是一個非常流暢的過程。但是如果對于比較大型的企業(yè)級應(yīng)用，需要對軟件質(zhì)量，對軟件的一些部署流程做更多的控制。這時候我們需要去集成很多額外的第三方工具，幫我們完成這些事情。對于這種開源社區(qū)里面，現(xiàn)在其實有非常多的工具，能夠把這一點點的，逐個逐個的綁定，我們不需要去重新做連接，我們需要把這些一個個的能夠平衡起來，并且用戶體驗上有可能不一致，能夠接入一些企業(yè)級的系統(tǒng)，有的可能是單獨一個系統(tǒng)，需要一些賬號，本身能夠接入的一些東西，我們直接就接入了，沒有問題。但是上面沒有插件的話，我們還接入不進來，就有這些問題，這是第三個比較大的問題。

除此以外還有很多很多，當我們做比較大型的軟件應(yīng)用的時候，我們可能需要考慮它的軟件高可用，是不是一個崩潰掉了，我們?nèi)康钠脚_都不可以用了，這樣整個團隊的研發(fā)進度一耽擱就不是錢的問題了。

現(xiàn)在除了剛才講的開源的工具以外，我們還有很多企業(yè)級的持續(xù)交付的工具，比較常見的話像teamcity、bamboo這些比較常見的，一些比較老牌企業(yè)的話可能還會用過IBM的Bluemix，Cloudbees是一個企業(yè)級方案，這套方案我個人認為不是特別好。這些工具就是解決了一些開源工具里面存在的一些問題，特別是性能的問題。但是當我們?nèi)ナ褂眠@些工具做一些web集成的時候，可能它里面已經(jīng)內(nèi)置一些我們常用東西的集成，但是有的東西是我們企業(yè)用過的，每個企業(yè)都會有一些特殊的東西，比如說資源審查的時候需要切入一些企業(yè)內(nèi)部的東西，這時候你會發(fā)現(xiàn)這些企業(yè)級產(chǎn)品在解決開源產(chǎn)品問題的時候，也引入了更大的封閉性。如果我發(fā)現(xiàn)一個問題不能解決的話，它就真的不能解決。它是開源工具的話，可能有一些社區(qū)方案，社區(qū)會提供一些插件，你不用干活，你拿過來用就可以。當你使用企業(yè)級方案的時候，它這個支持沒有。我們有一個想法是，如果我們現(xiàn)在想要選擇企業(yè)級的平臺，但是我們又想讓它能夠具有這個定制性，具有這個性能的話，我們能夠通過一些開源的工具，組合起來，讓這個工具變成一個平臺，變成一個企業(yè)級的平臺。

剛才王老師講的就是集成了各種各樣華為內(nèi)部開發(fā)者工具的云，包括持續(xù)交付，包括代碼的構(gòu)建、打包、部署等等這一系列的平臺。答案肯定是可以的，包括像現(xiàn)在華為應(yīng)該也是使用了一些開源組建，沒有必要把數(shù)據(jù)全部重新存，這樣會造成很大的完全沒有必要的消耗。如果要做這件事情的話可能會遇到什么問題，剛才講到各種各樣的問題。首先是性能問題，數(shù)據(jù)的集成問題，集成工具的問題，還有剛才提到的很多很多其他需要解決高可用、審計、權(quán)限、登錄等等，這些都是需要去解決的，它確實是有這個麻煩。以及一點我們信息要考慮現(xiàn)在比較流行的現(xiàn)代化的部署方式，我們也把它作為一個方案考慮進去。

我們現(xiàn)在看要解決這些問題的話有什么比較簡單的方式，或者是不會太費事的方式，把這個問題解決過去。首先說性能問題，由于大部分開源工具本身都不是為了這種大規(guī)模應(yīng)用設(shè)計的，它本身是確定存在的，但是它的規(guī)模上來之后，就會出現(xiàn)這種響應(yīng)速度慢，不可用的問題。我們要么去改原代碼，把它變成高可用的。

剛才提到的第二個問題是數(shù)據(jù)的集成，數(shù)據(jù)集成很簡單，所有的構(gòu)建，所有的測試，所有的部署，都在平臺上面做的，什么數(shù)據(jù)都有。但是從實際實踐來說的話我們可能會有多種思路，怎么去算這個數(shù)據(jù)。***種最簡單的，我們在代碼里面寫一個服務(wù)，每小時算一次，每天算一次，把報表算出來。這樣實現(xiàn)非常簡單，但是它的一個缺陷是，我們預(yù)定要算什么樣的數(shù)據(jù)就算什么樣的數(shù)據(jù)。它的數(shù)據(jù)算出來只是在你的數(shù)據(jù)庫里面的，如果持續(xù)算的話，對于數(shù)據(jù)庫來說的，這種大量計算的壓力很大，真正來做的話肯定是提前算好，大家讓我查誰就去查誰，提前做成一個表。第二個方式，我現(xiàn)在知道這兩年大數(shù)據(jù)這一塊的生態(tài)是非常多的，有很多這方面的高手，每個企業(yè)多少都會有一些做數(shù)據(jù)的人。我們也可以把這個數(shù)據(jù)接入到平臺來，無非就是一些數(shù)據(jù)表，我們可以分析具體到每一個人，具體到每一個子團體的變化，***可能是一個比較邪惡的平臺，講出來就不行了。但是這個方式成本會比較高，它能夠?qū)崿F(xiàn)的是實時的預(yù)算，也能夠提供一個基于這個數(shù)據(jù)深層次的挖掘，提供很多從外面很難看出來的一些存在的問題。

下面一個方式是我們在座其中一個嘗試當中去做的方法，在數(shù)據(jù)庫里面進行操作性是比較低的，但是我們可能通過一些專門做檢索，專門做搜索的工具，去做做搜索。

第三個是平臺集成，平臺集成對于開源來說是最最友好的事情，開源為什么叫開源，我們現(xiàn)在有大量可用的東西，是社區(qū)其他人開發(fā)出來貢獻出來的，我們可能只需要找到這個組建能夠用的。但是這個集成，如果這些東西我們在這個環(huán)境里面***都是一個，都是來自一些開發(fā)者，你去用，這個相當于增加了開發(fā)者的學(xué)習困難，他需要知道每個工具里面怎么用，甚至他可能會對這個不滿意。

這邊一般來說推薦一個做法，在我們真正的項目溝通需要集成的平臺之間做一個服務(wù)的索引，這樣的好處主要是為了方便升級，在這個上面可以做很多的事情。現(xiàn)在這種做法是比較推薦的接入第三方工具的一個做法。

其他的話，剛才提到的還有我們考慮高可用，需要考慮操作審計，權(quán)限等問題。高可用剛才提到了如果本身這個開源工具設(shè)置上就是高可用，我們要去做到高可用的話，就必須代到源代碼。我們現(xiàn)在有一個團隊在做這個事情，但是這個事情并不是沒有人都去嘗試的，因為從成本上很劃不來。如果說我們把每個項目都做了一個性能之后，我們系統(tǒng)本身做的是統(tǒng)一的，但是對于高可用的點，我們可以把它的，比如說每個(32：02)，和具體的項目進行對應(yīng)。當我們出現(xiàn)故障的時候，可能是單個的項目發(fā)生了問題，快速的重啟一個(32：17)，這樣只要把故障在一定程度上進行隔離，不會把這個故障延伸。這樣從使用的組織方式來避免這種故障發(fā)生，故障出問題了，我把它鎖定在一個項目組里面，或者鎖定在一個子項目組里面，把它做一個關(guān)聯(lián)，這是我們的事。

單點登錄的話，如果我們前端做一個界面，去屏蔽比較復(fù)雜的其他軟件的話，前端盡可能的把細節(jié)都屏蔽掉，屏蔽不掉的時候，當它暴露集成系統(tǒng)的時候，盡可能實現(xiàn)它的維護。就是它能夠不用(34：00%，或者如果不能單點登錄的話，就要賬號統(tǒng)一。構(gòu)建產(chǎn)物管理主要是為了部署做準備的，就是每個構(gòu)建出來的包我們需要把它管理起來，需要知道這些管理的包是不是一個。當我們?nèi)ミM行后續(xù)部署的時候，才知道是這一個包，這樣就能夠?qū)崿F(xiàn)部署。這些功能確切要求我們知道去布哪個包，但是對于用戶來說的話，如果讓用戶來選擇哪個包是你要做回購，他是找不出來的，就需要平臺進行管理，這樣比較節(jié)約時間，得到構(gòu)建的序號，能夠追溯這個東西。***這個東西是測試報告管理，測試報告主要是提供數(shù)據(jù)，提供后面的報表，或者是提供一些跟指標相關(guān)東西的內(nèi)容。

***一點是關(guān)于部署的邏輯化，這個邏輯化展開說的話會有很多，但是普遍上來說使用邏輯化的思路就在于，對于企業(yè)級的這種產(chǎn)品我們肯定不會單獨的使用，會在一個集群上使用。

我今天講的主要就是一個純技術(shù)的東西，不涉及到任何產(chǎn)品，也不涉及推薦任何東西的使用。這邊順便說一下，這個大家要做的話成本會比較高，雖然是我們低成本的開元工具的組合，但是如果你想要用這套工具的話，可以考慮剛才王老師提到的平臺劃分。謝謝大家，大家有什么問題。