2009年底翩蘸,比利時(shí)根特舉辦了第一屆DevOpsDays惜傲。Chris-Read作為嘉賓之一务冕,代表ThoughtWorks出席了這次活動(dòng)并帶來(lái)名為“持續(xù)集成硼身,流水線和部署”的演講拇囊。ThoughtWorks作為DevOps運(yùn)動(dòng)最早的見(jiàn)證者和奠基人迂曲,并沒(méi)有意識(shí)到這個(gè)周末聚會(huì)將在接下來(lái)10年給全球IT行業(yè)帶來(lái)深遠(yuǎn)影響。
1個(gè)月后寥袭,ThoughtWorks發(fā)布了第一期的技術(shù)雷達(dá)路捧。作為一個(gè)新興的名詞关霸,DevOps還沒(méi)有成熟到讓令人矚目的階段。然而杰扫,即便DevOps還沒(méi)有被納入技術(shù)雷達(dá)队寇,但與之相關(guān)的早期實(shí)踐和工具都已出現(xiàn)。在接下來(lái)的十年中章姓,DevOps已經(jīng)成為每期技術(shù)雷達(dá)不可或缺的一部分英上。從這個(gè)角度上說(shuō),技術(shù)雷達(dá)就是DevOps發(fā)展的見(jiàn)證者啤覆。
DevOps和技術(shù)雷達(dá)都將迎來(lái)自己的不愁之年苍日。作為IT行業(yè)技術(shù)的先行指標(biāo),技術(shù)雷達(dá)上面的技術(shù)平均領(lǐng)先行業(yè)3至5年窗声。也就是說(shuō)相恃,出現(xiàn)在技術(shù)雷達(dá)采納和試用區(qū)域的技術(shù),在3-5年后大概率將成為業(yè)界主流笨觅。
作為DevOps和技術(shù)雷達(dá)的粉絲拦耐,我想從技術(shù)雷達(dá)的角度總結(jié)DevOps的發(fā)展歷程。該系列文章共分為三篇见剩,分別是:
- DevOps和持續(xù)交付
- 基礎(chǔ)設(shè)施即代碼和云計(jì)算
- 容器技術(shù)和微服務(wù)
本文為“DevOps和技術(shù)雷達(dá)相伴十年”系列文章第一篇:DevOps和持續(xù)交付杀糯。
DevOps
雖然持續(xù)集成、構(gòu)建流水線和持續(xù)部署從技術(shù)雷達(dá)創(chuàng)刊號(hào)就存在苍苞。但DevOps作為一個(gè)正式條目進(jìn)入技術(shù)雷達(dá)的評(píng)估象限是在2010年8月的第三期技術(shù)雷達(dá)固翰。那時(shí),對(duì)DevOps的描述是這樣的:
“DevOps是一個(gè)新的運(yùn)動(dòng)羹呵,在尋找可以滿足業(yè)務(wù)需要的快速交付的軟件和穩(wěn)定的生產(chǎn)環(huán)境骂际。它擁有兩個(gè)目標(biāo):首先,讓開(kāi)發(fā)和運(yùn)維的合作更加緊密冈欢。其次歉铝,在運(yùn)維流程中應(yīng)用敏捷實(shí)踐(協(xié)作,自動(dòng)化凑耻,簡(jiǎn)單化)來(lái)處理初始化虛擬機(jī)太示,變更管理和生產(chǎn)環(huán)境監(jiān)控。它包含文化香浩、流程和工具类缤,全部用于支持更好的溝通,快速的交付和反饋以及可預(yù)測(cè)的產(chǎn)出上弃衍⊙椒牵”
半年后,DevOps運(yùn)動(dòng)所引發(fā)的影響越來(lái)越大镜盯。2011年1月岸裙,DevOps作為條目進(jìn)入了“試用”區(qū)域。這意味著至少ThoughtWorks內(nèi)部已經(jīng)全然接受DevOps速缆。在這一期的技術(shù)雷達(dá)中降允,對(duì)DevOps的描述做了一些調(diào)整:
DevOps運(yùn)動(dòng)持續(xù)讓人們關(guān)注經(jīng)常斷裂的開(kāi)發(fā)和運(yùn)維關(guān)系。DevOps提升了開(kāi)發(fā)和運(yùn)維的合作以及共同的責(zé)任艺糜。DevOps在運(yùn)維過(guò)程中應(yīng)用敏捷實(shí)踐,初始化虛擬機(jī)剧董,變更管理和生產(chǎn)環(huán)境監(jiān)控并為開(kāi)發(fā)階段引入了近似生產(chǎn)環(huán)境的思維,工具和環(huán)境破停。DevOps是對(duì)一個(gè)想對(duì)應(yīng)用發(fā)布到生產(chǎn)環(huán)境實(shí)施持續(xù)交付的關(guān)鍵基礎(chǔ)翅楼。
就像本文開(kāi)頭說(shuō)的,作為IT行業(yè)技術(shù)的先行指標(biāo)真慢,技術(shù)雷達(dá)一直都做得不錯(cuò)毅臊,出現(xiàn)在技術(shù)雷達(dá)上的技術(shù)平均領(lǐng)先行業(yè)3至5年。2011年6月黑界,DevOps正式進(jìn)入技術(shù)雷達(dá)的采納象限管嬉,這就意味著DevOps最晚在未來(lái)的5年中會(huì)成為業(yè)界的主流。
2012年3月朗鸠,技術(shù)雷達(dá)徹底更新了之前對(duì)DevOps的描述:
改進(jìn)開(kāi)發(fā)和IT運(yùn)營(yíng)的交互和關(guān)系讓有效的交付生產(chǎn)系統(tǒng)更加穩(wěn)定和可維護(hù)蚯撩。創(chuàng)建一個(gè)DevOps文化需要關(guān)注團(tuán)隊(duì)組織,工作實(shí)踐烛占,匯報(bào)線和激勵(lì)機(jī)制胎挎。它會(huì)帶來(lái)對(duì)更加快速和安全的交付的共同責(zé)任。我們推薦采用DevOps是因?yàn)槭强床坏饺魏螣o(wú)法帶來(lái)正面收益的情況忆家。
這也就是說(shuō)呀癣,在2012年,全球的ThoughtWorker們就已經(jīng)認(rèn)為在未來(lái)DevOps一定會(huì)帶來(lái)益處弦赖。而5年后的2017年项栏,北京才舉辦第一屆DevOpsDays,標(biāo)志了DevOps在中國(guó)發(fā)展的元年蹬竖。
最初沼沈,社區(qū)想讓運(yùn)維敏捷化,但DevOps走出了另外一條路币厕。
持續(xù)交付
我個(gè)人一直覺(jué)得列另,如果持續(xù)交付在2009年Velocity大會(huì)上出現(xiàn),DevOps很有可能不會(huì)出現(xiàn)旦装。
當(dāng)JezHumble于2010年第一次在DevOpsDays介紹持續(xù)交付的概念之后页衙,持續(xù)交付就成為了DevOps的核心實(shí)踐,直到現(xiàn)在。然而店乐,持續(xù)交付在一年后才進(jìn)入技術(shù)雷達(dá)艰躺,且第一次出現(xiàn)在技術(shù)雷達(dá)上的時(shí)候就直接落入了“采納環(huán)”,技術(shù)雷達(dá)是這么描述持續(xù)交付的:
如果你想知道“敏捷之后會(huì)發(fā)生什么”,你應(yīng)該關(guān)注持續(xù)交付眨八。雖然您的開(kāi)發(fā)流程可能已完全優(yōu)化,但您的組織可能需要數(shù)周或數(shù)月才能將單個(gè)更改轉(zhuǎn)化為生產(chǎn)腺兴。持續(xù)交付的重點(diǎn)是最大限度地實(shí)現(xiàn)自動(dòng)化,包括作為代碼的基礎(chǔ)架構(gòu)、環(huán)境管理和部署自動(dòng)化,以確保您的系統(tǒng)始終為生產(chǎn)做好準(zhǔn)備廉侧。它是關(guān)于收緊你的反饋循環(huán),而不是推遲任何東西,直到結(jié)束页响。持續(xù)交付與持續(xù)部署不同,這意味著將每個(gè)更改部署到生產(chǎn)環(huán)境。連續(xù)持續(xù)交付不是牛仔表演段誊。它讓您對(duì)生產(chǎn)環(huán)境負(fù)責(zé)闰蚕。企業(yè)可以選擇部署的內(nèi)容和時(shí)間。如果你認(rèn)為自己已經(jīng)確定了敏捷開(kāi)發(fā)的目標(biāo),但沒(méi)有考慮如何實(shí)現(xiàn)持續(xù)交付,你真的還沒(méi)有開(kāi)始连舍。
雖然DevOps比持續(xù)交付提前半年進(jìn)入了技術(shù)雷達(dá)没陡,但持續(xù)交付這一理念的各個(gè)組成部分早在技術(shù)雷達(dá)的創(chuàng)刊之前就存在了。
在2010年1月的技術(shù)雷達(dá)創(chuàng)刊號(hào)上烟瞧,“構(gòu)建流水線”(BuildPipeline)的概念就已經(jīng)處于技術(shù)雷達(dá)的“采納”環(huán)內(nèi)诗鸭。在持續(xù)交付出現(xiàn)之前,構(gòu)建流水線已經(jīng)連續(xù)4期穩(wěn)坐在技術(shù)雷達(dá)的“采納”環(huán)內(nèi)参滴。我們現(xiàn)在可以把構(gòu)建流水線看做是“持續(xù)集成”的一種擴(kuò)展實(shí)踐强岸,當(dāng)時(shí)它已經(jīng)被廣泛的運(yùn)用到了各種開(kāi)發(fā)項(xiàng)目上。
與此同時(shí)砾赔,“持續(xù)部署”(ContinuousDeployement)作為“軟件交付最后一公里”的實(shí)踐蝌箍,由于風(fēng)險(xiǎn)始終處于“評(píng)估”和“試用”階段。直到和持續(xù)交付同時(shí)出現(xiàn)在技術(shù)雷達(dá)上暴心。彼時(shí)妓盲,構(gòu)建流水線、持續(xù)部署和持續(xù)交付是三個(gè)不同的實(shí)踐专普。你可以簡(jiǎn)單的認(rèn)為“構(gòu)建流水線+持續(xù)部署=持續(xù)交付”悯衬,然而,持續(xù)交付所涉及的內(nèi)容卻不止涵蓋技術(shù)層面檀夹〗畲郑《持續(xù)交付》一書(shū)的作者JezHumble在其博客“持續(xù)交付vs持續(xù)部署”中詳細(xì)介紹了其中的區(qū)別:
首先,嚴(yán)格來(lái)說(shuō)炸渡,部署并不暗示發(fā)布娜亿,你可以持續(xù)的部署到UAT環(huán)境。讓持續(xù)部署變得特別的是把每一個(gè)改動(dòng)都通過(guò)自動(dòng)化測(cè)試(或者簡(jiǎn)短的QA門(mén)禁)部署到生產(chǎn)環(huán)境蚌堵。持續(xù)不是發(fā)布每一個(gè)良好構(gòu)建給用戶买决。這么說(shuō)來(lái)沛婴,更準(zhǔn)確的叫法應(yīng)該是“持續(xù)發(fā)布”督赤。
其次,持續(xù)交付是關(guān)于把發(fā)布計(jì)劃交給業(yè)務(wù)够挂,并不是交給IT來(lái)決策藕夫。實(shí)現(xiàn)持續(xù)交付意味著確定你的軟件在整個(gè)生命周期內(nèi)都是可以部署到生產(chǎn)環(huán)境上的孽糖。任何一個(gè)構(gòu)建都有機(jī)會(huì)通過(guò)自動(dòng)化的過(guò)程被發(fā)布給用戶毅贮。
但是,這并不是說(shuō)都把每次成功的構(gòu)建交付給用戶是一個(gè)好主意滩褥。特別是,有些嵌入式產(chǎn)品包括了軟件和硬件的變更瑰煎。在這些情況下,少次變更的感受可能會(huì)更好酒甸。關(guān)鍵在于,這些發(fā)布都是業(yè)務(wù)驅(qū)動(dòng)的插勤。
2011年6月份的技術(shù)雷達(dá)中,持續(xù)交付和DevOps同時(shí)出現(xiàn)在了的“采納”象限农尖。嚴(yán)格的說(shuō)析恋,DevOps并不是一項(xiàng)技術(shù)、也不是一種實(shí)踐盛卡,它是圍繞著一個(gè)理念的運(yùn)動(dòng)助隧。由于DevOps缺乏官方的定義,所以DevOps可以是任何東西滑沧。但持續(xù)交付不同并村,持續(xù)交付通過(guò)《持續(xù)交付》這本書(shū)傳播了一套完整和系統(tǒng)的方法論。這套系統(tǒng)的方法論和DevOps的理念不謀而合嚎货,因此橘霎,在DevOps社區(qū)內(nèi)被廣泛應(yīng)用。直至今日殖属,持續(xù)交付與否仍然是一個(gè)組織是否具備DevOps能力的一項(xiàng)關(guān)鍵能力姐叁。
換句話說(shuō),持續(xù)交付可以沒(méi)有DevOps,但DevOps不能沒(méi)有持續(xù)交付外潜。
技術(shù)雷達(dá)判斷的沒(méi)錯(cuò)原环,《持續(xù)交付》不光影響了DevOps,也影響了其它軟件領(lǐng)域处窥。隨著持續(xù)交付的盛行嘱吗,特別是流水線的概念深入人心,在不同領(lǐng)域誕生了不同的持續(xù)交付技術(shù)滔驾。例如:基礎(chǔ)設(shè)施流水線谒麦,鏡像構(gòu)建流水線,移動(dòng)設(shè)備的持續(xù)交付哆致。
持續(xù)交付和DevOps中的反模式
由于DevOps缺乏一個(gè)官方標(biāo)準(zhǔn)绕德,因此對(duì)DevOps的理解和實(shí)踐就會(huì)有所偏頗。在知道什么是“好的實(shí)踐”的過(guò)程中摊阀,我們也需要知道那些“不好的實(shí)踐”耻蛇,例如CI劇場(chǎng)(CITheatre):
長(zhǎng)期以來(lái),我們一直倡導(dǎo)持續(xù)集成(CI)胞此,我們是構(gòu)建CI服務(wù)器程序以自動(dòng)構(gòu)建簽入項(xiàng)目的先驅(qū)臣咖。使用得當(dāng)?shù)那闆r下,這些程序作為開(kāi)發(fā)人員每天承諾的共享項(xiàng)目主線上的守護(hù)進(jìn)程運(yùn)行漱牵。Ci服務(wù)器構(gòu)建項(xiàng)目并運(yùn)行全面測(cè)試夺蛇,以確保整個(gè)軟件系統(tǒng)集成并處于始終可發(fā)布的狀態(tài),從而滿足持續(xù)交付的原則布疙。遺憾的是,許多開(kāi)發(fā)人員只是設(shè)置了一個(gè)CI服務(wù)器截型,錯(cuò)誤地認(rèn)為他們正在“做CI”儒溉,而實(shí)際上他們錯(cuò)過(guò)了所有的好處。
常見(jiàn)的故障模式包括:對(duì)共享主干運(yùn)行CI,但很少提交波闹。因此集成并不是真正連續(xù)的;運(yùn)行測(cè)試覆蓋率較差的生成;允許構(gòu)建長(zhǎng)時(shí)間保持紅色卻不修復(fù);或?qū)μ卣鞣种н\(yùn)行CI,從而導(dǎo)致連續(xù)隔離精堕。隨后的"CI劇場(chǎng)"可能會(huì)讓人感覺(jué)很好,但卻會(huì)讓任何可信的CI失敗蒲障。
此外,很多人在理解持續(xù)集成(CI)的時(shí)候庄撮,就僅僅以為是安裝一個(gè)CI軟件(例如Jenkins)自動(dòng)化打包。而忽視了整個(gè)CI的九項(xiàng)關(guān)鍵原則:
- 維護(hù)單一代碼庫(kù)
- 自動(dòng)化構(gòu)建
- 讓構(gòu)建可以自測(cè)試
- 所有提交都要在一臺(tái)持續(xù)集成機(jī)器上進(jìn)行構(gòu)建
- 讓構(gòu)建保持快速
- 在類生產(chǎn)環(huán)境上進(jìn)行測(cè)試
- 讓任何人都可以輕松的取得最新的可執(zhí)行版本
- 每個(gè)人都可以看到發(fā)生了什么事情
- 自動(dòng)化部署
關(guān)于如何正確的做持續(xù)集成毡庆,可以參考ThoughtWorks官方的持續(xù)集成介紹么抗,進(jìn)一步了解詳情可以查看MartinFowler的原文厅翔。
此外刀闷,隨著持續(xù)集成這項(xiàng)實(shí)踐被廣泛采納仰迁。大型的項(xiàng)目也開(kāi)始遷移到持續(xù)集成服務(wù)器上,就會(huì)導(dǎo)致“為所有團(tuán)隊(duì)構(gòu)造單一CI實(shí)例”:
我們不得不再次告誡施蜜,不要為所有團(tuán)隊(duì)創(chuàng)建一個(gè)CI實(shí)例翻默。雖然在理論上整合和集中持續(xù)集成(CI)基礎(chǔ)結(jié)構(gòu)是一個(gè)不錯(cuò)的主意恰起,但實(shí)際上,我們?cè)谶@個(gè)空間的工具和產(chǎn)品中沒(méi)有看到足夠的成熟度來(lái)實(shí)現(xiàn)所需的結(jié)果肯污。軟件交付團(tuán)隊(duì)必須定期使用集中式CI產(chǎn)品蹦渣,這些團(tuán)隊(duì)會(huì)根據(jù)中央團(tuán)隊(duì)執(zhí)行次要配置任務(wù)或解決共享基礎(chǔ)結(jié)構(gòu)和工具中的問(wèn)題而長(zhǎng)時(shí)間的延遲貌亭。在這一階段,我們繼續(xù)建議各組織將其集中投資限于建立模式锄奢、準(zhǔn)則和支持交付團(tuán)隊(duì)運(yùn)行自己的CI基礎(chǔ)設(shè)施。
然而师坎,隨著CI不斷膨脹使得CI管理員不得不拆分流水線和自動(dòng)化測(cè)試堪滨,以便使得大型、緩慢的自動(dòng)化測(cè)試能夠獨(dú)立運(yùn)行遏乔。一個(gè)代碼庫(kù)被拆成多個(gè)代碼庫(kù)盟萨。一條流水線被拆成多條流水線了讨。既然能夠獨(dú)立測(cè)試、必然能夠獨(dú)立部署胞谭。于是男杈,慢慢的也就產(chǎn)生了微服務(wù)的概念伶棒。關(guān)于微服務(wù),我們將在以后講先蒋。
下面是持續(xù)交付和DevOps相關(guān)條目的發(fā)展歷程一覽圖舅锄。實(shí)線為同一條目的變化皇忿,虛線為影響的相關(guān)條目:
DevOps 和持續(xù)交付的理念在10年中不斷發(fā)酵鳍烁,影響了之后工具和技術(shù)的發(fā)展,技術(shù)雷達(dá)捕捉到了這些全球的趨勢(shì)糊闽。讓我們從最早開(kāi)始改變的數(shù)據(jù)中心和云計(jì)算看看 DevOps 帶來(lái)的影響。
敬請(qǐng)期待第二篇《從技術(shù)雷達(dá)看DevOps的十年——基礎(chǔ)設(shè)施即代碼和云計(jì)算》
相關(guān)條目:持續(xù)交付提澎,構(gòu)建流水線念链,持續(xù)部署,基礎(chǔ)設(shè)施流水線谦纱,鏡像構(gòu)建流水線缭付,移動(dòng)設(shè)備的持續(xù)交付吃嘿,Spinnaker。
文/ThoughtWorks顧宇
更多精彩洞見(jiàn)跳纳,請(qǐng)關(guān)注微信公眾號(hào):ThoughtWorks洞見(jiàn)