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

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

現場實錄如下：

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

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

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

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

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

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

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

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

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

除此以外還有很多很多，當我們做比較大型的軟件應用的時候，我們可能需要考慮它的軟件高可用，是不是一個崩潰掉了，我們全部的平臺都不可以用了，這樣整個團隊的研發進度一耽擱就不是錢的問題了。

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

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

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

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

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

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

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

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

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

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

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