持續(xù)交付：當(dāng)前普遍存在的三個(gè)問(wèn)題與解決方案

持續(xù)交付：當(dāng)前普遍存在的三個(gè)問(wèn)題與解決方案早在2009年，F(xiàn)lickr就分享了他們?nèi)绾瓮ㄟ^(guò)工具的支撐和文化的改變，使之能夠支撐業(yè)務(wù)部門“每天部署10次”的要求。這些工具包括：AutomatedinfraSharedversioncontrolOnestepbuildanddeployFeatureflagsSharedmetricsIRCandIMRobots5年時(shí)間過(guò)去了，隨著云計(jì)算和開源軟件的發(fā)展,我們擁有了比Flickr更好的基礎(chǔ)條件：IaaS給我們提供了可編程的接口，我們不再受到物理資源的約束；GitHub帶給我們新型版本控制和代碼協(xié)作方式；Chef/Puppet等配置和自動(dòng)化部署工具更加成熟；基于ELK的實(shí)時(shí)監(jiān)控和日志系統(tǒng)也很成熟。但是，即便如此，有多少企業(yè)達(dá)到了Flickr的持續(xù)部署和交付水平呢？這里，我們把持續(xù)交付分解成三條主線：從Code到Artifacts倉(cāng)庫(kù)；從Artifacts到RunningService；從開發(fā)、測(cè)試環(huán)境到準(zhǔn)生產(chǎn)、生產(chǎn)環(huán)境。對(duì)于這三條主線，筆者發(fā)現(xiàn)大部分IT組織都存在三個(gè)類似的問(wèn)題。1.從Code到Artifact倉(cāng)庫(kù)：沒(méi)有統(tǒng)一的Artifacts倉(cāng)庫(kù)在很多企業(yè)IT組織中，由于歷史及其他各種各樣的原因，不同的項(xiàng)目，會(huì)采用不同的開發(fā)語(yǔ)言、框架，版本控制服務(wù)和持續(xù)集成工具。這是不可避免的。真正的問(wèn)題是出在Artifact的管理上。有些人根本就沒(méi)有Artifact的概念，認(rèn)為代碼就是Artifact，部署應(yīng)用時(shí)都是直接從svn等版本控制器上面直接獲取代碼進(jìn)行部署。有些IT組織即便有Artifact倉(cāng)庫(kù)，也沒(méi)有統(tǒng)一的規(guī)范，非?；靵y。如何改進(jìn)呢？建立統(tǒng)一的Artifacts倉(cāng)庫(kù)。這是后續(xù)自動(dòng)化部署和多版本開發(fā)的基礎(chǔ)。Artifacts倉(cāng)庫(kù)的實(shí)現(xiàn)方式有三種，F(xiàn)TP、對(duì)象存儲(chǔ)（比如阿里云OSS,AWSS3等）和專業(yè)的Artifacts存儲(chǔ)倉(cāng)庫(kù)。對(duì)象存儲(chǔ)、FTP都重在存儲(chǔ)，只能實(shí)現(xiàn)最基礎(chǔ)的分目錄和權(quán)限管理。如果你的環(huán)境都在公有云上面，那么用公有云的對(duì)象存儲(chǔ)服務(wù)來(lái)管理Artifacts是很合適的，原因有以下幾個(gè)：?不用擔(dān)心可用性和可靠性；?上傳和下載速度快；?不同的項(xiàng)目可以用不同的Buckets來(lái)進(jìn)行權(quán)限管理。如果是AWSS3,還可以使用IAM來(lái)進(jìn)行更細(xì)粒度的權(quán)限控制。專業(yè)的Artifacts存儲(chǔ)倉(cāng)庫(kù)方面，目前有三個(gè)使用比較廣的選擇ArtifactoryNexus和Archiva其中Artifactory和Nexus也有商業(yè)版本。這三個(gè)工具雖然都源自Maven,但是他們不僅僅支持Java/Maven,任何項(xiàng)目和語(yǔ)言都可以使用Maven機(jī)制來(lái)打包Artifact，區(qū)分Artifact版本，并最終存儲(chǔ)到Repository中去。下圖是Nexus的一個(gè)截圖，可以清楚地看出Artifacts倉(cāng)庫(kù)所要解決的幾個(gè)問(wèn)題:不同項(xiàng)目、不同組件Artifacts的分類存儲(chǔ)；Artifacts格式的統(tǒng)一；用戶和權(quán)限控制；開發(fā)版本和發(fā)布版本區(qū)分、如何與CI服務(wù)器集成等。Frt2CkHj-dlReleasBEhcste-dl■「 ii■、PeleasBInServiceFrt2ClotdSnapsholshcstednaven2JSnapshotInSeirincshcsted二■川叮町凸=■—Jnaven21ReleaseInServiceSn^p-shDlEhostednavenSjSnapshotInServiceiIPit^Cloud區(qū)分幵發(fā)1?抵和炭布版本BrowseStorageBrowseIndesConftguratianMirrorsSummaryArtifactUpload迄jRefreshPainLookup: Pdt3Fh2ClcudRel&ases」亠呵 ―groupiD:頂耳魏別號(hào)類T8毗cloudj^aiyuri[D日eventagenL] aartifactld：組件dtjO.OlD[勺B7Entaqent-G-01Ci-source_zip1JArtifact!^容WejentaqEnkCda-souic已zp.md5-Je;eniageni-D..010-soLjce.^p.slial_[ejentagent-COldre出O0.D1L1JQd.diz出CjlO.313[出 ~] ”Artifact^本2.從Artifacts到Runningservice：不同環(huán)境的部署方法不一樣這條主線解決的是，如何將BuildArtifacts部署到開發(fā)環(huán)境、測(cè)試環(huán)境、準(zhǔn)生產(chǎn)環(huán)境和生產(chǎn)環(huán)境。對(duì)于這條主線，當(dāng)前普遍存在的問(wèn)題是：不同環(huán)境的資源創(chuàng)建、服務(wù)器配置和代碼部署方法是不一樣的。很多時(shí)候大家只關(guān)注生產(chǎn)環(huán)境的部署管理，對(duì)于開發(fā)及測(cè)試的部署管理又不重視。比如，開發(fā)和測(cè)試環(huán)境是手工部署的，而生產(chǎn)環(huán)境是用工具進(jìn)行自動(dòng)部署的，因?yàn)椴渴鸱绞讲灰恢?，所以在生產(chǎn)環(huán)境會(huì)經(jīng)常出現(xiàn)不可預(yù)知的錯(cuò)誤。另外，隨著版本分支的增加，開發(fā)、測(cè)試和準(zhǔn)生產(chǎn)環(huán)境會(huì)混亂不堪。如何改進(jìn)呢？貌似PaaS的存在就是為了解決這個(gè)問(wèn)題，開發(fā)人員只要專注于應(yīng)用的開發(fā)，部署和Ops工作都是有PaaS本身完成。然而，現(xiàn)實(shí)是目前的PaaS仍然沒(méi)有進(jìn)入主流，這是因?yàn)镻aaS給予太多的限制、很好解決的80%問(wèn)題，但是剩下20%很難解決。在云計(jì)算（laaS）支撐下，在云管理和部署工具的支持下（比如Rightscale,Cloudify,AWSCloudformation,AWSCodeDeploy,FIT2CLOUD），用戶可以實(shí)現(xiàn)從Artifacts到Runningservice整個(gè)過(guò)程的自動(dòng)化，包括環(huán)境創(chuàng)建自動(dòng)化、虛機(jī)安裝配置自動(dòng)化和代碼部署自動(dòng)化。1） 環(huán)境創(chuàng)建：創(chuàng)建VMs、網(wǎng)絡(luò)、存儲(chǔ)、負(fù)載均衡，協(xié)調(diào)不同角色VMs的創(chuàng)建過(guò)程和配置。2） 軟件安裝和配置：操作系統(tǒng)配置，比如創(chuàng)建用戶、組，設(shè)置Jlimit參數(shù)等；基礎(chǔ)軟件安裝和配置，比如Mysql/Nginx。這些軟件的特點(diǎn)是變動(dòng)不頻繁。3） 應(yīng)用部署（CodeDeploy）:部署應(yīng)用代碼，比如war包、db腳本、php/rails代碼等。這部分的變動(dòng)是頻繁的。開發(fā)人員不僅僅是提供代碼，而且要提供部署代碼所需的腳本，比

如AWSCodeDeploy規(guī)定Artifact中必須包括的部署這份代碼所需要的腳本。CodeDeploy雖然沒(méi)有編排功能及完備的插件和腳本庫(kù)（比如HP00）,但是實(shí)現(xiàn)了應(yīng)用代碼和部署腳本的統(tǒng)一融合，可以避免多版本同時(shí)開發(fā)、部署所導(dǎo)致的混亂。采用CodeDeploy，每個(gè)應(yīng)用組件可以單獨(dú)、持續(xù)的繼續(xù)升級(jí)部署，不需要整體部署。css/efror.jspftynts/Jfnages/iRdex.jspscnpts/css/efror.jspftynts/Jfnages/iRdex.jspscnpts/sialic/~V/EBINF/os:Unuxfiles:-source:jdesiiiiaiion.ftwf^e/ei^-usef/iomcai/webapps/hooks:gQfarelns呼 _-bcalfor;[scripts/ciiec^dppendefKjQS.sbttmeour ~iuhas:rootAfterlnstaif:-locslian:^chpts/ch3nge_pennissions.shtimeout3OTluna^jrootAppliCAtimStart;-tofauoirL[s^jpLS/iJa^se^veisJt血TfiOLTt300AppiicattonStop:mn&s:eo2-userAppiicattonStop:3.從開發(fā)、測(cè)試環(huán)境到準(zhǔn)生產(chǎn)、生產(chǎn)環(huán)境：開發(fā)、QA和運(yùn)營(yíng)仍然采用傳統(tǒng)的協(xié)作方式這條主線涉及IT組織內(nèi)部的合作和協(xié)調(diào)。傳統(tǒng)的協(xié)作方式及流程的設(shè)計(jì)是依據(jù)當(dāng)時(shí)'非頻繁”交付設(shè)計(jì)的，不適應(yīng)于當(dāng)前對(duì)頻繁交付的要求。IT組織仍然固守傳統(tǒng)的運(yùn)作和分工機(jī)制，做一件事需要開很多會(huì)，是一種類似瀑布流的組織方式，需要花很多時(shí)間。當(dāng)下很多IT組織采用了敏捷開發(fā)、每天都可以產(chǎn)生很多構(gòu)建（Build），但是生產(chǎn)環(huán)境的部署節(jié)奏仍然很慢，這是普遍存在的問(wèn)題。如何改進(jìn)呢？實(shí)現(xiàn)DTAP的融合需要三個(gè)方面的支持：觀念的轉(zhuǎn)變，組織結(jié)構(gòu)和文化的更新及技術(shù)和工具的支撐。首先是觀念上面的改變，并建立與新觀念相匹配的共享服務(wù)Metric和SLA信息。在競(jìng)爭(zhēng)激烈的新時(shí)代，原來(lái)那種Dev和Ops隔離的方式已經(jīng)滿足不了云時(shí)代的快速迭代交互的需求。傳統(tǒng)觀念新觀念開發(fā)人員的工作是：增加新功能運(yùn)維人員的工作是：保持服務(wù)穩(wěn)定、快速開發(fā)人、運(yùn)營(yíng)、測(cè)試、項(xiàng)目管理人員的共同工作是：enablethebusiness其次是工具和流程上面的改進(jìn)。基于上面第一條、第二條主線達(dá)成的基礎(chǔ)，構(gòu)建自動(dòng)化的文化，并建立清晰、一致的DTAP流程。這樣Dev、Ops、QA因?yàn)槭窃谝粋€(gè)流程和同樣工具下工作的，相互所有的細(xì)節(jié)都透明了，也就自然融合了。同時(shí),DTAP環(huán)境都是用相同的方式進(jìn)行自動(dòng)化部署的，在進(jìn)行生產(chǎn)環(huán)境部署前，這個(gè)部署方法已經(jīng)在開發(fā)、測(cè)試、準(zhǔn)生產(chǎn)環(huán)境上面被反復(fù)驗(yàn)證過(guò)?？偠灾媒y(tǒng)一的流程和工具管理不同的環(huán)境，又能支持不同環(huán)境的不同策略，這是實(shí)現(xiàn)DTAP環(huán)境融合在技術(shù)和工具上的關(guān)鍵所在。環(huán)境(Erw)目標(biāo)用戶（Users）構(gòu)建類型(BuildType)部署者(Deployer/Owner)Dev｛開發(fā)環(huán)境）開炭人員平穩(wěn)定眾本（實(shí)時(shí)自動(dòng)構(gòu)建〕ci自動(dòng)融塩（自動(dòng)祁MTest｛測(cè)試環(huán)境）漏試人員不理定飯豐｛毎天自動(dòng)枸建｝口目則融步Acceptance（準(zhǔn)生產(chǎn)環(huán)境）內(nèi)鄒用戶塩芾顧木（人二融握）訊譽(yù)輕制臺(tái)（人工觸長(zhǎng)］Production（生產(chǎn)環(huán)境）匪塔用戶塩和S牙｛人二觸發(fā)》耶暑輕制臺(tái)（AIMS）最后，不同角色人員之間相互融合。比如，開發(fā)人員應(yīng)該更加深入地參與測(cè)試及生產(chǎn)環(huán)境的運(yùn)營(yíng)，比如參與測(cè)試環(huán)境的部署、生產(chǎn)環(huán)境各個(gè)層面監(jiān)控指標(biāo)的設(shè)計(jì)和開發(fā)?！癥oubuildit,yourunit”，這是Amazon一年可以完成5000萬(wàn)次部署，平均每個(gè)工程師每天部署超過(guò)50次的核心秘籍。結(jié)士束語(yǔ)結(jié)束語(yǔ)持續(xù)部署、持續(xù)交付能力的改進(jìn)，是一個(gè)從自身情況出發(fā)的，持續(xù)的、不斷改進(jìn)的過(guò)程。在文章結(jié)束之前，我還想分享下我的兩個(gè)體會(huì)。1.不能把希望完全寄托在新興的技術(shù)，比如Docker，來(lái)提升持續(xù)交付能力。很多人盼著Docker來(lái)解決現(xiàn)在存在的問(wèn)題。但這些問(wèn)題都不需要Docker就可解決，Netflix/Flickr等就是例子，關(guān)鍵得有持續(xù)改