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

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

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