早在2009年，F(xiàn)lickr就分享了他們?nèi)绾瓮ㄟ^工具的支持和文化的改變，使之能夠支撐業(yè)務(wù)部門“每天部署10次”的要求。這些工具包括

• Automated infra
• Shared version control
• One step build and deploy
• Feature flags
• Shared metrics
• IRC and IM Robots

5年時(shí)間過去了，隨著云計(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倉庫;
• 從Artifacts到Running Service;
• 從開發(fā)、測試環(huán)境到準(zhǔn)生產(chǎn)、生產(chǎn)環(huán)境;

對于這三條主線，筆者發(fā)現(xiàn)大部分IT組織都存在三個(gè)類似的問題。

1. 從Code到Artifact倉庫：沒有統(tǒng)一的Artifacts倉庫

在很多企業(yè)IT組織中，由于歷史及其他各種各樣的原因，不同的項(xiàng)目，會采用不同的開發(fā)語言、框架，版本控制服務(wù)和持續(xù)集成工具。這是不可避免的。真正的問題是出在Artifact的管理上。有些人根本就沒有Artifact的概念，認(rèn)為代碼就是artifact，部署應(yīng)用時(shí)都是直接從svn等版本控制器上面直接獲取代碼進(jìn)行部署。有些IT組織即便有aritfact倉庫，也沒有統(tǒng)一的規(guī)范，非常混亂。

如何改進(jìn)呢?

建立統(tǒng)一的Artifacts倉庫。這是后續(xù)自動(dòng)化部署和多版本開發(fā)的基礎(chǔ)。

Artifacts倉庫的實(shí)現(xiàn)方式有三種，F(xiàn)TP、對象存儲(比如阿里云OSS，AWS S3等)和專業(yè)的Artifacts存儲倉庫。對象存儲、 FTP都重在存儲，只能實(shí)現(xiàn)最基礎(chǔ)的分目錄和權(quán)限管理。如果你的環(huán)境都在公有云上面，那么用公有云的對象存儲服務(wù)來管理Artifacts是很合適的，原因有以下幾個(gè)：

• 不用擔(dān)心可用性和可靠性。
• 上傳和下載速度快。
• 不同的項(xiàng)目可以用不同的Buckets來進(jìn)行權(quán)限管理。如果是AWS S3，還可以使用IAM來進(jìn)行更細(xì)粒度的權(quán)限控制。

專業(yè)的Artifacts存儲倉庫方面，目前有三個(gè)使用比較廣的選擇：Artifactory、Nexus和Archiva，其中Artifactory和Nexus也有商業(yè)版本。這三個(gè)工具雖然都源自Maven，但是他們不僅僅支持Java/Maven，任何項(xiàng)目和語言都可以使用Maven機(jī)制來打包Artifact，區(qū)分Artifact版本，并最終存儲到Repository中去。下圖是Nexus的一個(gè)截圖，可以清楚看出Artifacts倉庫所要解決的幾個(gè)問題：不同項(xiàng)目、不同組件artifacts的分類存儲;Artifacts格式的統(tǒng)一;用戶和權(quán)限控制;開發(fā)版本和發(fā)布版本區(qū)分、如何與CI服務(wù)器集成等。

2. 從Artifacts到Running service：不同環(huán)境的部署方法不一樣

這條主線解決的是，如何將Build artifacts部署到開發(fā)環(huán)境、測試環(huán)境、準(zhǔn)生產(chǎn)環(huán)境和生產(chǎn)環(huán)境。

對于這條主線，當(dāng)前普遍存在的問題是：不同環(huán)境的資源創(chuàng)建、服務(wù)器配置和代碼部署方法是不一樣的。很多時(shí)候大家只關(guān)注生產(chǎn)環(huán)境的部署管理，對于開發(fā)及測試的部署管理又不重視。比如，開發(fā)和測試環(huán)境是手工部署的，而生產(chǎn)環(huán)境是用工具進(jìn)行自動(dòng)部署的，因?yàn)椴渴鸱绞讲灰恢拢驗(yàn)樵谏a(chǎn)環(huán)境會經(jīng)常出現(xiàn)不可預(yù)知的錯(cuò)誤。另外，隨著版本分支的增加，開發(fā)、測試和準(zhǔn)生產(chǎn)環(huán)境會混亂不堪。

如何改進(jìn)呢?

貌似PaaS的存在就是為了解決這個(gè)問題，開發(fā)人員只要專注于應(yīng)用的開發(fā)，部署和Ops工作都是有PaaS本身完成。然而，現(xiàn)實(shí)是目前的PaaS仍然沒有進(jìn)入主流，這是因?yàn)镻aaS給予太多的限制、很好解決的80%問題，但是剩下20%很難解決。

在云計(jì)算(IaaS)支撐下，在云管理和部署工具的支持下(比如Rightscale, Cloudify，AWS Cloudformation, AWS CodeDeploy, FIT2CLOUD)，用戶可以實(shí)現(xiàn)從Artifacts到Running service整個(gè)過程的自動(dòng)化，包括環(huán)境創(chuàng)建自動(dòng)化、虛機(jī)安裝配置自動(dòng)化和代碼部署自動(dò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è)置ulimit參數(shù)等;基礎(chǔ)軟件安裝和配置，比如mysql/nginx。這些軟件的特點(diǎn)是變動(dòng)不頻繁。
3. 應(yīng)用部署(Code Deploy)：部署應(yīng)用代碼，比如war包、db腳本、php/rails代碼等。這部分的變動(dòng)是頻繁的。開發(fā)人員不僅僅是提供代碼，而且要提供部署代碼所需的腳本，比如AWS CodeDeploy規(guī)定Artifact中必須包括的部署這份代碼所需要的腳本。CodeDeploy雖然沒有編排功能及完備的插件和腳本庫(比如HP OO)，但是實(shí)現(xiàn)了應(yīng)用代碼和部署腳本的統(tǒng)一融合，可以避免多版本同時(shí)開發(fā)、部署所導(dǎo)致的混亂。采用CodeDeploy，每個(gè)應(yīng)用組件可以單獨(dú)、持續(xù)的繼續(xù)升級部署，不需要整體部署。

#p#

3. 從開發(fā)、測試環(huán)境到準(zhǔn)生產(chǎn)、生產(chǎn)環(huán)境：開發(fā)、QA和運(yùn)營仍然采用傳統(tǒng)的協(xié)作方式

這條主線涉及IT組織內(nèi)部的合作和協(xié)調(diào)。傳統(tǒng)的協(xié)作方式及流程的設(shè)計(jì)是依據(jù)當(dāng)時(shí)”非頻繁”交付設(shè)計(jì)的，不適應(yīng)于當(dāng)前對頻繁交付的要求。IT組織仍然固守傳統(tǒng)的運(yùn)作和分工機(jī)制，做一件事需要開很多會，是一種類似瀑布流的組織方式，需要花很多時(shí)間。當(dāng)下很多IT組織采用了敏捷開發(fā)、每天都可以產(chǎn)生很多構(gòu)建(Build)，但是生產(chǎn)環(huán)境的部署節(jié)奏仍然很慢，這是普遍存在的問題。

如何改進(jìn)呢?

實(shí)現(xiàn)DTAP的融合需要三個(gè)方面支持：觀念的轉(zhuǎn)變，組織結(jié)構(gòu)和文化的更新及技術(shù)和工具的支撐。

首先是觀念上面的改變，并建立與新觀念相匹配的共享服務(wù)Metric和SLA信息。在競爭激烈的新時(shí)代，原來那種Dev和Ops隔離的方式已經(jīng)滿足不了云時(shí)代的快速迭代交互的需求。

其次是工具和流程上面的改進(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ā)、測試、準(zhǔn)生產(chǎn)環(huán)境上面被反復(fù)驗(yàn)證過?？偠灾?，用統(tǒng)一的流程和工具管理不同的環(huán)境，又能支持不同環(huán)境的不同策略，這是實(shí)現(xiàn)DTAP環(huán)境融合在技術(shù)和工具上的關(guān)鍵所在。

***，不同角色人員之間相互融合。比如，開發(fā)人員應(yīng)該更加深入的參與測試及生產(chǎn)環(huán)境的運(yùn)營，比如參與測試環(huán)境的部署、生產(chǎn)環(huán)境各個(gè)層面監(jiān)控指標(biāo)的設(shè)計(jì)和開發(fā)。“You build it, you run it“，這是Amazon一年可以完成5000萬次部署，平均每個(gè)工程師每天部署超過50次的核心秘籍。

結(jié)束語

持續(xù)部署、持續(xù)交付能力的改進(jìn)，是一個(gè)從自身情況出發(fā)的，持續(xù)的、不斷改進(jìn)的過程。在文章結(jié)束之前，我還想分享下我的兩個(gè)體會。

1.不能把希望完全寄托在新興的技術(shù)，比如Docker，來提升持續(xù)交付能力。很多人盼著Docker來解決現(xiàn)在存在的問題。但這些問題都不需要Docker就可解決，Netflix/ Flickr等就是例子，關(guān)鍵得有持續(xù)改進(jìn)的意愿和行動(dòng)。松耦合的SOA/微服務(wù)架構(gòu); “you build it, you run it”的DevOps文化; 與架構(gòu)和文化相適應(yīng)的自動(dòng)化工具和Infra。這三點(diǎn)都不是一朝一夕或者一個(gè)新技術(shù)可以解決的。

2.IaaS會是新常態(tài)，將成為互聯(lián)網(wǎng)和企業(yè)的基礎(chǔ)設(shè)施。云IT和傳統(tǒng)IT有很大的不同。 使用IaaS只是***步，企業(yè)應(yīng)該利用上云這個(gè)契機(jī)，在應(yīng)用架構(gòu)、部署管理工具、開發(fā)運(yùn)維協(xié)作方式也進(jìn)行轉(zhuǎn)變，解決這三個(gè)普遍存在的問題，打通從代碼到服務(wù)的通道，提升持續(xù)交付能力。

【本文來源：fit2cloud微信公眾號】