1.1　軟件工程發(fā)展概述

“軟件工程”這一學(xué)科出現(xiàn)于1968年，當(dāng)時(shí)正值第一次軟件危機(jī)。第一次軟件危機(jī)是落后的軟件生產(chǎn)方式無法滿足迅速增長(zhǎng)的計(jì)算機(jī)軟件需求，從而導(dǎo)致軟件開發(fā)與維護(hù)過程中出現(xiàn)一系列嚴(yán)重問題的現(xiàn)象。人們?cè)噲D借鑒建筑工程領(lǐng)域的工程方法來解決這一問題，以實(shí)現(xiàn)“按預(yù)算準(zhǔn)時(shí)交付所需功能的軟件項(xiàng)目”的愿望。

1.1.1　瀑布軟件開發(fā)方法

瀑布軟件開發(fā)模型由Dr. Winston W. Rovce在1970年發(fā)表的“Managing the development of large software systems”一文首次提出，如圖1-1所示。它將軟件開發(fā)過程定義為多個(gè)階段，每個(gè)階段均有嚴(yán)格的輸入和輸出標(biāo)準(zhǔn)，項(xiàng)目管理者希望通過這種重計(jì)劃、重流程、重文檔的方式來解決軟件危機(jī)。很多人將具有以上3個(gè)特征的軟件開發(fā)方法統(tǒng)稱為“重型軟件開發(fā)方法”。

圖1-1　瀑布軟件開發(fā)模型

在20世紀(jì)，瀑布軟件開發(fā)模型的每個(gè)階段都需要花費(fèi)數(shù)月的時(shí)間。在寫出第一行產(chǎn)品代碼之前，甲乙雙方需要花費(fèi)大量精力確定需求范圍，審核比《新華字典》厚得多的軟件需求規(guī)格說明書。即便如此，雙方還是要為“是否發(fā)生了需求范圍的變更”“是否準(zhǔn)時(shí)交付了軟件”“交付的軟件是否滿足了預(yù)先設(shè)定的業(yè)務(wù)需求”而糾纏不清。

1.1.2　敏捷軟件開發(fā)方法

從20世紀(jì)80年代開始，微型計(jì)算機(jī)快速普及。20世紀(jì)90年代，人們對(duì)軟件的需求迅速擴(kuò)大。然而，Standish Group的Chaos Report 1994顯示，軟件交付項(xiàng)目的失敗或交付困難的比率仍舊很高（成功率只有16.2%，受到挑戰(zhàn)的項(xiàng)目占比52.7%，而失敗率為31.1%）。此時(shí)，很多優(yōu)秀的軟件工作者不滿意瀑布軟件開發(fā)方法的交付成果，并在各自工作實(shí)踐中總結(jié)了各種新的軟件開發(fā)方法，例如我們現(xiàn)在經(jīng)常聽說的Scrum和極限編程，都是在那個(gè)時(shí)代涌現(xiàn)出來的軟件開發(fā)方法。

2001年，17位軟件大師齊聚美國猶他州的一個(gè)小鎮(zhèn)——雪鳥（Snowbird），總結(jié)了當(dāng)時(shí)涌現(xiàn)的這些輕量級(jí)軟件開發(fā)方法所具備的特點(diǎn)，共同發(fā)表了“敏捷宣言”，提出敏捷軟件開發(fā)方法應(yīng)該遵循的十二原則，見附錄A。與會(huì)人員一致同意，凡符合這一宣言所倡導(dǎo)的價(jià)值觀且遵循十二開發(fā)原則的方法均可被認(rèn)為是“敏捷軟件開發(fā)方法”。因此，“敏捷軟件開發(fā)方法”這一說法從其誕生開始就是一簇軟件開發(fā)方法的代名詞，而不是特指某一種軟件開發(fā)方法。

敏捷軟件開發(fā)方法強(qiáng)調(diào)發(fā)揮人的主觀能動(dòng)性，提倡面對(duì)面溝通、擁抱變化、通過迭代和增量開發(fā)盡早交付有價(jià)值的軟件。此時(shí)，很多團(tuán)隊(duì)已認(rèn)識(shí)到，軟件開發(fā)實(shí)際上是一個(gè)不斷迭代學(xué)習(xí)的過程，即軟件工程師需要快速學(xué)習(xí)并理解領(lǐng)域知識(shí)，并將其轉(zhuǎn)化成數(shù)字世界的表達(dá)形式，通過與業(yè)務(wù)專家的交流討論來學(xué)習(xí)并持續(xù)迭代這個(gè)過程。一個(gè)軟件交付計(jì)劃被劃分成多個(gè)迭代，強(qiáng)調(diào)在每個(gè)迭代結(jié)束時(shí)應(yīng)該得到可運(yùn)行的軟件，如圖1-2所示。

圖1-2　迭代開發(fā)，多批次部署發(fā)布

與瀑布軟件開發(fā)方法只在項(xiàng)目交付后期才能看到可運(yùn)行的軟件相比，敏捷軟件開發(fā)方法在這方面有很大的進(jìn)步。“持續(xù)集成”作為敏捷開發(fā)方法中的一個(gè)工程實(shí)踐，率先被更廣泛的IT組織所接受，即便那些沒有采納敏捷開發(fā)方法的團(tuán)隊(duì)也會(huì)使用它，因?yàn)槠鋸?qiáng)調(diào)的頻繁自動(dòng)化構(gòu)建和自動(dòng)化測(cè)試減少了質(zhì)量保障團(tuán)隊(duì)的重復(fù)工作量，也排除了開發(fā)團(tuán)隊(duì)與質(zhì)量保障團(tuán)隊(duì)之間的溝通障礙。

當(dāng)時(shí)的主流軟件需求仍舊是來自企業(yè)級(jí)定制軟件開發(fā)。雖然敏捷開發(fā)方法使用的是迭代模型，但兩次軟件發(fā)布之間的間隔時(shí)間仍舊較長(zhǎng)（通常是數(shù)月，甚至一年以上）。因此，業(yè)務(wù)人員與研發(fā)團(tuán)隊(duì)之間關(guān)于需求變更和研發(fā)效率的矛盾仍舊是主要矛盾。系統(tǒng)的部署發(fā)布工作在整個(gè)發(fā)布周期中所占用的時(shí)間和成本相對(duì)較小，部署和運(yùn)維工作還不是突出矛盾。另外，部署活動(dòng)通常由專門的技術(shù)運(yùn)維團(tuán)隊(duì)執(zhí)行，產(chǎn)品研發(fā)團(tuán)隊(duì)對(duì)其無感。

在這一時(shí)期，無論瀑布開發(fā)還是敏捷開發(fā)，在軟件行業(yè)中最重要的關(guān)注點(diǎn)都是可交付的軟件包本身，即如何快速地將軟件需求變?yōu)榭山桓兜能浖?/p>

1.1.3　DevOps運(yùn)動(dòng)

DevOps的萌芽源于2008年8月敏捷大會(huì)多倫多站的一個(gè)臨時(shí)話題“敏捷基礎(chǔ)設(shè)施”（Agile Infrastructure）。當(dāng)時(shí)比利時(shí)獨(dú)立IT咨詢師Patrick Debois非常感興趣，并且分享了關(guān)于“將敏捷實(shí)踐應(yīng)用于運(yùn)維領(lǐng)域”。2009年10月，Patrick在比利時(shí)的根特組織了一個(gè)“DevOpsDays”社區(qū)會(huì)議，并正式啟用了“DevOps”這個(gè)術(shù)語。

2010年“The Agile Admin”網(wǎng)站上發(fā)表的一篇題為“What is DevOps”（什么是DevOps）的文章中指出：“DevOps是一組概念集合的代稱，雖然并非全部都是新概念，但它們已經(jīng)催化為一種運(yùn)動(dòng)，并迅速在整個(gè)技術(shù)社區(qū)中傳播。”同時(shí)，該文章也給出了其原始定義，即“DevOps是運(yùn)維工程師和開發(fā)工程師參與整個(gè)服務(wù)生命周期（從設(shè)計(jì)到開發(fā)再到生產(chǎn)支持）的一組實(shí)踐”，并提出，DevOps應(yīng)該倡導(dǎo)運(yùn)維人員更多地使用和開發(fā)人員使用的相同技術(shù)來進(jìn)行系統(tǒng)運(yùn)維工作。

DevOps在維基百科上的定義也在隨著時(shí)間的推進(jìn)而不斷變化著。截止到2017年，其定義為：

DevOps是一種軟件工程文化和實(shí)踐，旨在統(tǒng)一整合軟件開發(fā)和軟件運(yùn)維。DevOps運(yùn)動(dòng)的主要特點(diǎn)是強(qiáng)烈倡導(dǎo)對(duì)構(gòu)建軟件的所有環(huán)節(jié)（從集成、測(cè)試、發(fā)布到部署和基礎(chǔ)架構(gòu)管理）進(jìn)行全面的自動(dòng)化和監(jiān)控。DevOps的目標(biāo)是縮短開發(fā)周期，提高部署頻率和更可靠地發(fā)布，與業(yè)務(wù)目標(biāo)保持一致。

事實(shí)上，到寫作本書之時(shí)，業(yè)界對(duì)DevOps并沒有統(tǒng)一的標(biāo)準(zhǔn)定義。正如“敏捷”一樣，每一位從業(yè)者、每一個(gè)企業(yè)都有自己所理解的DevOps。有些人認(rèn)為DevOps是敏捷的一個(gè)子集，有些人認(rèn)為“敏捷做對(duì)了，就是DevOps”，還有人則將DevOps看作圍繞自動(dòng)化實(shí)施的一套實(shí)踐，或多或少與敏捷有些關(guān)聯(lián)性。

從歷史時(shí)間點(diǎn)上來看，DevOps源于敏捷思想和實(shí)踐在運(yùn)維領(lǐng)域的應(yīng)用，但當(dāng)時(shí)的實(shí)操指導(dǎo)性不足，而近乎同期出版的《持續(xù)交付》一書使其更加具象化，在企業(yè)實(shí)踐方面更具有可操作性。書中給出了一系列的原則、方法與實(shí)踐，使DevOps運(yùn)動(dòng)的參與者有線索可循，例如持續(xù)交付中強(qiáng)烈倡導(dǎo)的“一切皆代碼，自動(dòng)化一切，部署流水線盡早反饋”等。

DevOps并非一個(gè)標(biāo)準(zhǔn)、一種模式或者一套固定方法，而是一種IT組織管理的發(fā)展趨勢(shì)，也就是說，通過多種方式打破IT職能部門之間的隔閡，改變IT組織內(nèi)部的原有合作模式，使之更緊密結(jié)合，從而促進(jìn)業(yè)務(wù)迭代速度更快。這種發(fā)展趨勢(shì)將會(huì)引起IT組織內(nèi)部原有角色與分工的變化，甚至范圍更大，會(huì)影響到相關(guān)的業(yè)務(wù)組織。對(duì)互聯(lián)網(wǎng)公司來說，其軟件產(chǎn)品對(duì)業(yè)務(wù)發(fā)展起到極其關(guān)鍵的作用，業(yè)務(wù)結(jié)果與IT效能強(qiáng)關(guān)聯(lián)，因此順應(yīng)這一發(fā)展趨勢(shì)的動(dòng)力更加明顯和迫切。

既然DevOps是一種組織管理的發(fā)展趨勢(shì)，那么它就是IT領(lǐng)域普適的。對(duì)于不同行業(yè)、不同企業(yè)中的IT組織，需要根據(jù)其所在行業(yè)的行業(yè)特點(diǎn)以及企業(yè)實(shí)際狀況進(jìn)行一系列的管理定制。

1.1.4　持續(xù)交付1.0

2006年，Jez Humble、Chris Read和Dan North共同發(fā)表了一篇題為“The Deployment Production Line”（部署生產(chǎn)線）的文章。文中討論了軟件部署帶來的生產(chǎn)效率問題，并首次提出“部署生產(chǎn)線”模式：

……測(cè)試和部署是軟件開發(fā)過程中最困難且耗時(shí)的階段。即使團(tuán)隊(duì)已經(jīng)使用自動(dòng)構(gòu)建完成了代碼的測(cè)試工作，也需要幾天時(shí)間做生產(chǎn)部署的情況仍舊很常見……我們描述的原則和實(shí)踐使你可以一鍵創(chuàng)建、配置和部署新的環(huán)境。

……通過多階段自動(dòng)化工作流程，測(cè)試和部署過程可以完全自動(dòng)化。利用這種“部署生產(chǎn)線”，可以將已經(jīng)過驗(yàn)證的代碼快速部署到生產(chǎn)環(huán)境中，并且一旦發(fā)生問題，就可以輕松地回退到以前的版本。

該文章的3位作者當(dāng)年均就職于ThoughtWorks公司，而該公司是敏捷軟件開發(fā)方法的踐行者、倡導(dǎo)者和推廣者。該公司使用的軟件開發(fā)方法也源自極限編程方法。作者通過各自的實(shí)踐總結(jié)出了“部署流水線”模式的雛形，并且對(duì)如何使自動(dòng)化部署活動(dòng)更輕松給出了以下4條指導(dǎo)原則。

（1）每個(gè)構(gòu)建階段都應(yīng)該交付可工作的軟件，即中間產(chǎn)物的生成（例如搭建軟件框架）不應(yīng)該是一個(gè)單獨(dú)的階段。

（2）用同一個(gè)制品（artifact）向不同類型的環(huán)境部署，即將其與運(yùn)行時(shí)配置分開管理。

（3）自動(dòng)化測(cè)試和部署，即根據(jù)測(cè)試目的，分成幾個(gè)獨(dú)立的質(zhì)量關(guān)卡。

（4）這個(gè)部署生產(chǎn)線設(shè)計(jì)也應(yīng)該隨著你的應(yīng)用程序的發(fā)展而不斷演進(jìn)。

2007年，ThoughtWorks公司的Dave Farley也發(fā)表了一篇題為“The Deployment Pipeline- Extending the range of Continuous Integration”（部署流水線——持續(xù)集成的延伸）的文章。文中指出，部署流水線就是通過自動(dòng)化方式將多個(gè)質(zhì)量驗(yàn)證關(guān)卡及其中的驗(yàn)證內(nèi)容聯(lián)系在一起，如圖1-3所示。

圖1-3　Dave Farley在2007年定義的部署流水線

同年12月，ThoughtWorks在北京正式組建了產(chǎn)品研發(fā)團(tuán)隊(duì)，啟動(dòng)了以這種部署流水線為指導(dǎo)思想的軟件持續(xù)發(fā)布管理工具的研發(fā)。當(dāng)時(shí)Jez Humble是產(chǎn)品經(jīng)理，我負(fù)責(zé)該產(chǎn)品的交付與業(yè)務(wù)分析。該產(chǎn)品的第一個(gè)版本發(fā)布于2008年7月，取名為Cruise（現(xiàn)名為GoCD）。其最重要的一個(gè)功能特性就是“部署流水線”（deployment pipeline）。而且很多特性設(shè)計(jì)（包括內(nèi)置的制品倉庫、多階段之間的制品引用）也體現(xiàn)了“一次構(gòu)建，多次使用”的原則。

在開發(fā)GoCD期間，Jez Humble和Dave Farley合著了《持續(xù)交付》一書，英文版于2010年正式出版，該書于2011年獲得Jolt杰出大獎(jiǎng)，中文版也于2011年在國內(nèi)上市，這標(biāo)志著“持續(xù)交付”這一術(shù)語的正式誕生。Jez Humble說：“持續(xù)交付是一種能力，也就是說，能夠以可持續(xù)方式，安全快速地把代碼變更（包括特性、配置、缺陷和試驗(yàn)）部署到生產(chǎn)環(huán)境上，讓用戶使用。”本書將這一定義稱為“持續(xù)交付1.0”。

在《持續(xù)交付》一書中，講述了持續(xù)交付1.0所遵循的理念、原則和眾多方法與實(shí)踐，并在該書最后一章指出：“它不僅僅是一種新的軟件交付方法論，而且對(duì)依賴軟件的業(yè)務(wù)來說，是一個(gè)全新的范式^[1]。”

持續(xù)交付1.0提供的很多原則及方法是DevOps運(yùn)動(dòng)的具體實(shí)操指引，它們可以為企業(yè)的IT團(tuán)隊(duì)將DevOps運(yùn)動(dòng)落地實(shí)施提供非常具體的指導(dǎo)，如圖1-4所示。

圖1-4　持續(xù)交付將發(fā)布權(quán)交還給業(yè)務(wù)方

從所涉及的協(xié)作角色來看，敏捷開發(fā)更多地涉及產(chǎn)品需求方、軟件開發(fā)工程師和軟件測(cè)試工程師。在歷史上，DevOps更多地涉及軟件研發(fā)團(tuán)隊(duì)（包括開發(fā)工程師和測(cè)試工程師）與運(yùn)維工程師，而持續(xù)交付1.0涉及產(chǎn)品需求方、軟件研發(fā)團(tuán)隊(duì)和運(yùn)維工程師，如圖1-5所示。

圖1-5　相關(guān)概念在組織角色的主要觸達(dá)點(diǎn)

持續(xù)部署與持續(xù)交付

很多人認(rèn)為，持續(xù)部署（continuous deployment）是持續(xù)交付（continuous delivery）的進(jìn)階狀態(tài)，是指代碼提交后一旦成功通過所有質(zhì)量驗(yàn)證，就立即自動(dòng)部署到生產(chǎn)環(huán)境中，不需要任何人的審批。事實(shí)上，“部署”與“交付”這兩個(gè)主干詞的意義并不相同。

“部署”是一種技術(shù)領(lǐng)域的操作，也就是說，從某處獲取軟件包，并按照預(yù)先設(shè)計(jì)的方案將其安裝到計(jì)算節(jié)點(diǎn)上，并確保系統(tǒng)可以正常啟動(dòng)，但它并不一定意味著“必須包含業(yè)務(wù)功能的發(fā)布或交付”。“交付”則是一個(gè)業(yè)務(wù)決策活動(dòng)，通常也被稱為“發(fā)布”，也就是說，如果將新構(gòu)建的特性交付到客戶（用戶）手中，用戶就可以看到并使用它們。

之所以“部署”與“發(fā)布”幾乎成為等價(jià)詞，是歷史原因造成的。很久以前，軟件的發(fā)布周期較長(zhǎng)，每次新功能部署之后就會(huì)立即發(fā)布。久而久之，“部署”就成了“發(fā)布”的代名詞。為了保證軟件質(zhì)量，IT部門通常不允許無關(guān)代碼（即與本次發(fā)布新特性集合無關(guān)，例如未開發(fā)完成的功能、不完善的功能集）被帶到生產(chǎn)環(huán)境中。因此，每次部署就一定是重大功能的發(fā)布。

隨著互聯(lián)網(wǎng)軟件的出現(xiàn)，“部署”和“發(fā)布”內(nèi)容與頻率不同的情況也是很常見的。我們可以向環(huán)境多次部署，但只有當(dāng)業(yè)務(wù)需要時(shí)才向用戶發(fā)布，如圖1-4中的箭頭所示。例如，F(xiàn)acebook公司的發(fā)布工程師Chuck Rossi在2011年該公司舉辦的技術(shù)分享會(huì)上指出：“我們現(xiàn)在每天會(huì)對(duì)Facebook網(wǎng)站進(jìn)行一次部署操作……Facebook公司在半年后將要主推的功能特性，現(xiàn)在已經(jīng)上線了，只是用戶看不到而已。”