軟件交付的問題
    1.1　引言
    作為軟件從業(yè)人員，我們面臨的最重要問題就是，如果有人想到了一個好點子，我們?nèi)绾我宰羁斓乃俣葘⑺�交付給用戶？本書將給出這個問題的答案。
    我們將專注于構(gòu)建、部署、測試和發(fā)布過程，因為相對于軟件生產(chǎn)全過程的其他環(huán)節(jié)來說，這部分內(nèi)容的論著較為稀少。確切地說，我們并不認為軟件開發(fā)方法不重要，如果沒有對軟件生命周期中其他方面的關(guān)注，只把它們作為全部問題的次要因素草率對待的話，就不可能實現(xiàn)可靠、迅速且低風險的軟件發(fā)布，無法以高效的方式將我們的勞動成果交到用戶手中。
    現(xiàn)在有很多種軟件開發(fā)方法，但它們主要關(guān)注于需求管理及其對開發(fā)工作的影響。市面上也有很多優(yōu)秀的書，它們詳細討論了在軟件設(shè)計、開發(fā)和測試方面各種各樣的方法，但它們都僅僅講述了將軟件交付給作為客戶的人或組織這一完整價值流的一部分。
    一旦完成了需求定義以及方案的設(shè)計、開發(fā)和測試，我們接下來做什么？我們?nèi)绾螀f(xié)調(diào)這些活動，盡可能地使交付過程更加可靠有效呢？我們?nèi)绾巫岄_發(fā)人員、測試人員，以及構(gòu)建和運維人員在一起高效地工作呢？
    本書描述了軟件從開發(fā)到發(fā)布這一過程的有效模式。書中講述了幫助大家實現(xiàn)這種模式的技術(shù)和最佳實踐，展示了它與軟件交付中其他活動是如何聯(lián)系的。
    本書的中心模式是部署流水線。從本質(zhì)上講，部署流水線就是指一個應(yīng)用程序從構(gòu)建、部署、測試到發(fā)布這整個過程的自動化實現(xiàn)。部署流水線的實現(xiàn)對于每個組織都將是不同的，這取決于他們對軟件發(fā)布的價值流的定義，但其背后的原則是相同的。
    部署流水線的示例如圖1-1所示。
    部署流水線大致的工作方式如下。對于應(yīng)用程序的配置、源代碼、環(huán)境或數(shù)據(jù)的每個變更都會觸發(fā)創(chuàng)建一個新流水線實例的過程。流水線的首要步驟之一就是創(chuàng)建二進制文件和安裝包，而其余部分都是基于第一步的產(chǎn)物所做的一系列測試，用于證明其達到了發(fā)布質(zhì)量。每通過一步測試，我都會更加相信這些二進制文件、配置信息、環(huán)境和數(shù)據(jù)所構(gòu)成的特殊組合可以正常工作。如果這個產(chǎn)品通過了所有的測試環(huán)節(jié)，那么它就可以發(fā)布了。
    圖1-1　一個簡單的部署流水線
    部署流水線以持續(xù)集成過程為其理論基石，從本質(zhì)上講，它是采納持續(xù)集成原理后的自然結(jié)果。
    部署流水線的目標有三個。首先，它讓軟件構(gòu)建、部署、測試和發(fā)布過程對所有人可見，促進了合作。其次，它改善了反饋，以便在整個過程中，我們能夠更早地發(fā)現(xiàn)并解決問題。最后，它使團隊能夠通過一個完全自動化的過程在任意環(huán)境上部署和發(fā)布軟件的任意版本。
    1.2　一些常見的發(fā)布反模式
    軟件發(fā)布的當天往往是緊張的一天。為什么會這樣呢？對于大多數(shù)項目來說，在整個過程中，發(fā)布時的風險是比較大的。
    在許多軟件項目中，軟件發(fā)布是一個需要很多手工操作的過程。首先，由運維團隊獨自負責安裝好該應(yīng)用程序所需的操作系統(tǒng)環(huán)境，再把應(yīng)用程序所依賴的第三方軟件安裝好。其次，要手工將應(yīng)用程序的軟件產(chǎn)物復制到生產(chǎn)主機環(huán)境，然后通過Web服務(wù)器、應(yīng)用服務(wù)器或其他第三方系統(tǒng)的管理控制臺復制或創(chuàng)建配置信息，再把相關(guān)的數(shù)據(jù)復制一份到環(huán)境中，最后啟動應(yīng)用程序。假如這是個分布式的或面向服務(wù)的應(yīng)用程序，可能就需要一部分一部分地完成。
    如上所述，發(fā)布當天緊張的原因應(yīng)該比較清楚了：在這個過程中有太多步驟可能出錯。假如其中有一步?jīng)]有完美地執(zhí)行，應(yīng)用程序就無法正確地運行。一旦發(fā)生這種情況，我們很難一下子說清楚哪里出了錯，或到底是哪一步出了錯。
    本書其他部分將討論如何避免這些風險，如何減少發(fā)布當天的壓力，以及如何確保每次發(fā)布的可靠性都是可預見的。
    在此之前，讓我們先明確到底要避免哪類失敗。下面列出了與可靠的發(fā)布過程相對應(yīng)的幾種常見的反模式，它們在我們這個行業(yè)中屢見不鮮。
    1.2.1　反模式：手工部署軟件
    對于現(xiàn)在的大多數(shù)應(yīng)用程序來說，無論規(guī)模大小，其部署過程都比較復雜，而且包含很多非常靈活的部分。許多組織都使用手工方式發(fā)布軟件，也就是說部署應(yīng)用程序所需的步驟是獨立的原子性操作，由某個人或某個小組來分別執(zhí)行。每個步驟里都有一些需要人為判斷的事情，因此很容易發(fā)生人為錯誤。即便不是這樣，這些步驟的執(zhí)行順序和時機的不同也會導致結(jié)果的差異性，而這種差異性很可能給我們帶來不良后果。
    這種反模式的特征如下。
    · 有一份非常詳盡的文檔，該文檔描述了執(zhí)行步驟及每個步驟中易出錯的地方。
    · 以手工測試來確認該應(yīng)用程序是否運行正確。
    · 在發(fā)布當天開發(fā)團隊頻繁地接到電話，客戶要求解釋部署為何會出錯。
    · 在發(fā)布時，常常會修正一些在發(fā)布過程中發(fā)現(xiàn)的問題。
    · 如果是集群環(huán)境部署，常常發(fā)現(xiàn)在集群中各環(huán)境的配置都不相同，比如應(yīng)用服務(wù)器的連接池設(shè)置不同或文件系統(tǒng)有不同的目錄結(jié)構(gòu)等。
    · 發(fā)布過程需要較長的時間（超過幾分鐘）。
    · 發(fā)布結(jié)果不可預測，常常不得不回滾或遇到不可預見的問題。
    · 發(fā)布之后凌晨兩點還睡眼惺忪地坐在顯示器前，絞盡腦汁想著怎么讓剛剛部署的應(yīng)用程序能夠正常工作。
    相反，隨著時間的推移，部署應(yīng)該走向完全自動化，即對于那些負責將應(yīng)用程序部署到開發(fā)環(huán)境、測試環(huán)境或生產(chǎn)環(huán)境的人來說，應(yīng)該只需要做兩件事：（1）挑選版本及需要部署的環(huán)境，（2）按一下“部署”按鈕。對于套裝軟件的發(fā)布來說，還應(yīng)該有一個創(chuàng)建安裝程序的自動化過程。
    我們將在本書中討論很多自動化問題。當然，并不是所有的人都熱衷于這個想法。那么，我們先來解釋一下為什么把自動化部署看做是一個必不可少的目標。
    · 如果部署過程沒有完全自動化，每次部署時都會發(fā)生錯誤。唯一的問題就是“該問題嚴重與否”而已。即便使用良好的部署測試，有些錯誤也很難追查。
    · 如果部署過程不是自動化的，那么它就既不可重復也不可靠，就會在調(diào)試部署錯誤的過程中浪費很多時間。
    · 手動部署流程不得不被寫在文檔里�？墒俏臋n維護是一項復雜而費時的任務(wù)，它涉及多人之間的協(xié)作，因此文檔通常要么是不完整的，要么就是未及時更新的，而把一套自動化部署腳本作為文檔，它就永遠是最新且完整的，否則就無法進行部署工作了。
    · 自動部署本質(zhì)上也是鼓勵協(xié)作的，因為所有內(nèi)容都在一個腳本里，一覽無遺。要讀懂文檔通常需要讀者具備一定的知識水平。然而在現(xiàn)實中，文檔通常只是為執(zhí)行部署者寫的備忘錄，是難以被他人理解的。
    · 以上幾點引起的一個必然結(jié)果：手工部署過程依賴于部署專家。如果專家去度假或離職了，那你就有麻煩了。
    · 盡管手工部署枯燥且極具重復性，但仍需要有相當程度的專業(yè)知識。若要求專家做這些無聊、重復，但有技術(shù)要求的任務(wù)則必定會出現(xiàn)各種我們可以預料到的人為失誤，同時失眠，酗酒這種問題也會接踵而至。然而自動化部署可以把那些成本高昂的資深高技術(shù)人員從過度工作中解放出來，讓他們投身于更高價值的工作活動當中。
    · 對手工部署過程進行測試的唯一方法就是原封不動地做一次（或者幾次）。這往往費時，還會造成高昂的金錢成本，而測試自動化的部署過程卻是既便宜又容易。
    · 另外，還有一種說法：自動化過程不如手工過程的可審計性好。我們對這個觀點感到很疑惑。對于一個手工過程來說，沒人能確保其執(zhí)行者會非常嚴格地遵循文檔完成操作。只有自動化過程是完全可審核的。有什么會比一個可工作的部署腳本更容易被審核的呢？
    · 每個人都應(yīng)該使用自動化部署過程，而且它應(yīng)該是軟件部署的唯一方式。這個準則可以確保：在需要部署時，部署腳本就能完成工作。在本書中我們會提到多個原則，而其中之一就是“使用相同的腳本將軟件部署到各種環(huán)境上”。如果使用相同的腳本將軟件部署到各類環(huán)境中，那么在發(fā)布當天需要向生產(chǎn)環(huán)境進行部署時，這個腳本已經(jīng)被驗證過成百上千次了。如果發(fā)布時出現(xiàn)任何問題的話，你可以百分百地確定是該環(huán)境的具體配置問題，而不是這個腳本的問題。
    當然，手工密集型的發(fā)布工作有時也會進行得非常順利。有沒有可能是糟糕的情況剛巧都被我們撞見了呢？假如在整個軟件生產(chǎn)過程中它還算不上一個易出錯的步驟，那么為什么還總要這么嚴陣以待呢？為什么需要這些流程和文檔呢？為什么團隊在周末還要加班呢？為什么還要求大家原地待命，以防意外發(fā)生呢？
    1.2.2　反模式：開發(fā)完成之后才向類生產(chǎn)環(huán)境部署
    在這一模式下，當軟件被第一次部署到類生產(chǎn)環(huán)境（比如試運行環(huán)境）時，就是大部分開發(fā)工作完成時，至少是開發(fā)團隊認為“該軟件開發(fā)完成了”。
    這種模式中，經(jīng)常出現(xiàn)下面這些情況。
    · 如果測試人員一直參與了在此之前的過程，那么他們已在開發(fā)機器上對軟件進行了測試。
    · 只有在向試運行環(huán)境部署時，運維人員才第一次接觸到這個新應(yīng)用程序。在某些組織中，通常是由獨立的運維團隊負責將應(yīng)用程序部署到試運行環(huán)境和生產(chǎn)環(huán)境。在這種工作方式下，運維人員只有在產(chǎn)品被發(fā)布到生產(chǎn)環(huán)境時才第一次見到這個軟件。
    · 有可能由于類生產(chǎn)環(huán)境非常昂貴，所以權(quán)限控制嚴格，操作人員自己無權(quán)對該環(huán)境進行操作，也有可能環(huán)境沒有按時準備好，甚至也可能根本沒人去準備環(huán)境。
    · 開發(fā)團隊將正確的安裝程序、配置文件、數(shù)據(jù)庫遷移腳本和部署文檔一同交給那些真正執(zhí)行部署任務(wù)的人員，而所有這些都沒有在類生產(chǎn)環(huán)境或試運行環(huán)境中進行過測試。
    · 開發(fā)團隊和真正執(zhí)行部署任務(wù)的人員之間的協(xié)作非常少。
    每當需要將軟件部署到試運行環(huán)境時，都要組建一個團隊來完成這項任務(wù)。有時候這個團隊是一個全功能團隊。然而在大型組織中，這種部署責任通常落在多個分立的團隊肩上。DBA、中間件團隊、Web團隊，以及其他團隊都會涉及應(yīng)用程序最后版本的部署工作。由于部署工作中的很多步驟根本沒有在試運行環(huán)境上測試過，所以常常遇到問題。比如，文檔中漏掉了一些重要的步驟，文檔和腳本對目標環(huán)境的版本或配置作出錯誤的假設(shè)，從而使部署失敗。部署團隊必須猜測開發(fā)團隊的意圖。
    若不良協(xié)作使得在試運行環(huán)境上的部署工作問題重重，就會通過臨時撥打電話、發(fā)電子郵件來溝通，并由開發(fā)人員做快速修復。一個嚴格自律的團隊會將所有這類溝通納入部署計劃中，但這個過程很少有效。隨著部署壓力的增大，為了能夠在規(guī)定的時間內(nèi)完成部署，開發(fā)團隊與部署團隊之間這種嚴格定義的協(xié)作過程將被顛覆。
    在執(zhí)行部署過程中，我們常常發(fā)現(xiàn)系統(tǒng)設(shè)計中存在對生產(chǎn)環(huán)境的錯誤假設(shè)。例如，部署的某個應(yīng)用軟件是用文件系統(tǒng)做數(shù)據(jù)緩存的。這在開發(fā)環(huán)境中是沒有什么問題的，但在集群環(huán)境中可能就不行了。解決這類問題可能要花很長時間，而且在問題解決之前，根本無法完成應(yīng)用程序的部署。
    一旦將應(yīng)用程序部署到了試運行環(huán)境，我們常常會發(fā)現(xiàn)新的缺陷。遺憾的是，我們常常沒有時間修復所有問題，因為最后期限馬上就到了，而且項目進行到這個階段時，推遲發(fā)布日期是不能被人接受的。所以，大多數(shù)嚴重缺陷被匆忙修復，而為了安全起見，項目經(jīng)理會保存一份已知缺陷列表，可是當下一次發(fā)布開始時，這些缺陷的優(yōu)先級還是常常被排得很低。
    有的時候，情況會比這還糟。以下這些事情會使與發(fā)布相關(guān)的問題惡化。
    · 假如一個應(yīng)用程序是全新開發(fā)的，那么第一次將它部署到試運行環(huán)境時，可能會非常棘手。
    · 發(fā)布周期越長，開發(fā)團隊在部署前作出錯誤假設(shè)的時間就越長，修復這些問題的時間也就越長。
    · 交付過程被劃分到開發(fā)、DBA、運維、測試等部門的那些大型組織中，各部門之間的協(xié)作成本可能會非常高，有時甚至會將發(fā)布過程拖上“地獄列車”。此時為了完成某個部署任務(wù)（更糟糕的情況是，為了解決部署過程中出現(xiàn)的問題），開發(fā)人員、測試人員和運維人員總是高舉著問題單（不斷地互發(fā)電子郵件）。
    · 開發(fā)環(huán)境與生產(chǎn)環(huán)境差異性越大，開發(fā)過程中所做的那些假設(shè)與現(xiàn)實之間的差距就越大。雖然很難量化，但我敢說，如果在Windows系統(tǒng)上開發(fā)軟件，而最終要部署在Solaris集群上，那么你會遇到很多意想不到的事情。
    · 如果應(yīng)用程序是由用戶自行安裝的（你可能沒有太多權(quán)限來對用戶的環(huán)境進行操作），或者其中的某些組件不在企業(yè)控制范圍之內(nèi)，此時可能需要很多額外的測試工作。
    那么，我們的對策就是將測試、部署和發(fā)布活動也納入到開發(fā)過程中，讓它們成為開發(fā)流程正常的一部分。這樣的話，當準備好進行系統(tǒng)發(fā)布時就幾乎很少或不會有風險了，因為你已經(jīng)在很多種環(huán)境，甚至類生產(chǎn)環(huán)境中重復過很多次，也就相當于測試過很多次了。而且要確保每個人都成為這個軟件交付過程的一份子，無論是構(gòu)建發(fā)布團隊、還是開發(fā)測試人員，都應(yīng)該從項目開始就一起共事。
    我們是測試的狂熱者，而大量使用持續(xù)集成和持續(xù)部署（不但對應(yīng)用程序進行測試，而且對部署過程進行測試）正是我們所描述的方法的基石。
    1.2.3　反模式：生產(chǎn)環(huán)境的手工配置管理
    很多組織通過專門的運維團隊來管理生產(chǎn)環(huán)境的配置。如果需要修改一些東西，比如修改數(shù)據(jù)庫的連接配置或者增加應(yīng)用服務(wù)器線程池中的線程數(shù)，就由這個團隊登錄到生產(chǎn)服務(wù)器上進行手工修改。如果把這樣一個修改記錄下來，那么就相當于是變更管理數(shù)據(jù)庫中的一條記錄了。
    這種反模式的特征如下。
    · 多次部署到試運行環(huán)境都非常成功，但當部署到生產(chǎn)環(huán)境時就失敗。
    · 集群中各節(jié)點的行為有所不同。例如，與其他節(jié)點相比，某個節(jié)點所承擔的負載少一些，或者處理請求的時間花得多一些。
    · 運維團隊需要較長時間為每次發(fā)布準備環(huán)境。
    · 系統(tǒng)無法回滾到之前部署的某個配置，這些配置包括操作系統(tǒng)、應(yīng)用服務(wù)器、關(guān)系型數(shù)據(jù)庫管理系統(tǒng)、Web服務(wù)器或其他基礎(chǔ)設(shè)施設(shè)置。
    · 不知道從什么時候起，集群中的某些服務(wù)器所用的操作系統(tǒng)、第三方基礎(chǔ)設(shè)施、依賴庫的版本或補丁級別就不同了。
    · 直接修改生產(chǎn)環(huán)境上的配置來改變系統(tǒng)配置。
    相反，對于測試環(huán)境、試運行環(huán)境和生產(chǎn)環(huán)境的所有方面，尤其是系統(tǒng)中的任何第三方元素的配置，都應(yīng)該通過一個自動化的過程進行版本控制。
    本書描述的關(guān)鍵實踐之一就是配置管理，其責任之一就是讓你能夠重復地創(chuàng)建那些你開發(fā)的應(yīng)用程序所依賴的每個基礎(chǔ)設(shè)施。這意味著操作系統(tǒng)、補丁級別、操作系統(tǒng)配置、應(yīng)用程序所依賴的其他軟件及其配置、基礎(chǔ)設(shè)施的配置等都應(yīng)該處于受控狀態(tài)。你應(yīng)該具有重建生產(chǎn)環(huán)境的能力，最好是能通過自動化的方式重建生產(chǎn)環(huán)境。虛擬化技術(shù)在這一點上可能對你有所幫助。
    你應(yīng)該完全掌握生產(chǎn)環(huán)境中的任何信息。這意味著生產(chǎn)環(huán)境中的每次變更都應(yīng)該被記錄下來，而且做到今后可以查閱。部署失敗經(jīng)常是因為某個人在上次部署時為生產(chǎn)環(huán)境打了補丁，但卻沒有將這個修改記錄下來。實際上，不應(yīng)該允許手工改變測試環(huán)境、試運行環(huán)境和生產(chǎn)環(huán)境，而只允許通過自動化過程來改變這些環(huán)境。
    應(yīng)用軟件之間通常會有一些依賴關(guān)系。我們應(yīng)該很容易知道當前發(fā)布的是軟件的哪個版本。
    發(fā)布可能是一件令人興奮的事情，也可能變成一件累人而又沉悶的工作。幾乎在每次發(fā)布的最后都會有一些變更，比如修改數(shù)據(jù)庫的登錄賬戶或者更新所用外部服務(wù)的URL。我們應(yīng)該使用某種方法來引入此類變更，以便這些變更可以被記錄并測試。這里我們再次強調(diào)一下，自動化是關(guān)鍵。變更首先應(yīng)該被提交到版本控制系統(tǒng)中，然后通過某個自動化過程對生產(chǎn)環(huán)境進行更新。
    我們也應(yīng)該有能力在部署出錯時，通過同一個自動化過程將系統(tǒng)回滾到之前的版本。
    1.2.4　我們能做得更好嗎
    當然可以，本書就是來講如何做好這件事的。即使是在一個非常復雜的企業(yè)環(huán)境中，我們所說的這些原則、實踐和技術(shù)的目標都是將軟件發(fā)布工作變成一個沒有任何突發(fā)事件且索然無味的事情。軟件發(fā)布能夠（也應(yīng)該）成為一個低風險、頻繁、廉價、迅速且可預見的過程。這些實踐在過去的幾年中已經(jīng)被使用，并且我們發(fā)現(xiàn)它們令很多項目變得非比尋常。本書所提到的所有實踐既在具有分布式團隊的大型企業(yè)項目中驗證過，也在小型開發(fā)組中驗證過。我們確信它們是有效的，而且可以應(yīng)用在大項目中。
    自動化部署的威力
    曾經(jīng)有個客戶，他們在過去每次發(fā)布時都會組建一個較大的專職團隊。大家在一起工作七天（包括周末的兩天）才能把應(yīng)用程序部署到生產(chǎn)環(huán)境中。他們的發(fā)布成功率很低，要么是發(fā)現(xiàn)了錯誤，要么是在發(fā)布當天需要高度干預，且常常要在接下來的幾天里修復在發(fā)布過程中引入的問題或者是配置新軟件時導致的人為問題。
    我們幫助客戶實現(xiàn)了一個完善的自動構(gòu)建、部署、測試和發(fā)布系統(tǒng)。為了讓這個系統(tǒng)能夠良好運行下去，我們還幫助他們采用了一些必要的開發(fā)實踐和技術(shù)。我們看到的最后一次發(fā)布，只花了七秒鐘就將應(yīng)用程序部署到了生產(chǎn)環(huán)境中。根本沒有人意識到發(fā)生了什么，只是感覺突然間多了一些新功能。假如部署失敗了，無論是什么原因，我們都可以在同樣短的時間里回滾。
    本書的目標是描述如何使用部署流水線，將高度自動化的測試和部署以及全面的配置管理結(jié)合在一起，實現(xiàn)一鍵式軟件發(fā)布。也就是說，只需要點擊一下鼠標，就可以將軟件部署到任何目標環(huán)境，包括開發(fā)環(huán)境、測試環(huán)境或生產(chǎn)環(huán)境。
    接下來，我們會描述這種模式及其所需的技術(shù)，并提供一些建議幫你解決將面臨的某些問題。實現(xiàn)這種方法，實在是磨刀不誤砍柴工。
    所有這些工作并不會超出項目團隊的能力范圍。它不需要剛性的流程、大量的文檔或很多人力。我們希望，讀完本章以后，你會理解這種方法背后的原則。
    1.3　如何實現(xiàn)目標
    正如我們所說，作為軟件從業(yè)者，我們的目標是盡快地向用戶交付有用的可工作的軟件。
    速度是至關(guān)重要的，因為未交付的軟件就意味著機會成本。軟件發(fā)布之時就是投資得到回報之時。因此，本書有兩個目標，其中之一就是找到減少周期時間（cycle time）的方法。周期時間是從決定進行變更的時刻開始，包括修正缺陷或增加特性，直至用戶可以使用本次變更后的結(jié)果。
    快速交付也是非常重要的，因為這使你能夠驗證那些新開發(fā)的特性或者修復的缺陷是否真的有用。決定開發(fā)這個應(yīng)用程序的人（我們稱為客戶）會猜測哪些特性或缺陷修復對用戶是有用的。然而，直到使用者真正使用之前，這些全是未經(jīng)過驗證的假設(shè)。這也是為什么減少周期時間并建立有效反饋環(huán)如此重要的原因。
    有用性的一個重要部分是質(zhì)量。我們的軟件應(yīng)該滿足它的業(yè)務(wù)目的。質(zhì)量并不等于完美，正如伏爾泰所說“追求完美是把事情做好的大敵”，但我們的目標應(yīng)該一直是交付質(zhì)量足夠高的軟件，給客戶帶來價值。因此，盡快地交付軟件很重要，保證一定的質(zhì)量是基礎(chǔ)。
    因此，我們來調(diào)整一下目標，即找到可以以一種高效、快速、可靠的方式交付高質(zhì)量且有價值的軟件的方法。
    我們及我們的同修發(fā)現(xiàn)，為了達到這些目標（短周期、高質(zhì)量），我們需要頻繁且自動化地發(fā)布軟件。為什么呢？
    · 自動化。如果構(gòu)建、部署、測試和發(fā)布流程不是自動化的，那它就是不可重復的。由于軟件本身、系統(tǒng)配置、環(huán)境以及發(fā)布過程的不同，每次做完這些活動以后，其結(jié)果可能都會有所不同。由于每個步驟都是手工操作，所以出錯的機會很大，而且無法確切地知道具體都做了什么。這意味著整個發(fā)布過程無法得到應(yīng)有的控制來確保高質(zhì)量。常常說軟件發(fā)布像是一種藝術(shù)，但事實上，它應(yīng)該是一種工程學科。
    · 頻繁做。如果能夠做到頻繁發(fā)布，每個發(fā)布版本之間的差異會很小。這會大大減少與發(fā)布相關(guān)的風險，且更容易回滾。頻繁發(fā)布也會加快反饋速度，而客戶也需要它。本書很多內(nèi)容都聚焦于如何盡快得到對軟件及其相關(guān)配置所做變化的反饋，這包括其環(huán)境、部署過程及數(shù)據(jù)等。
    對于頻繁地自動化發(fā)布來說，反饋是至關(guān)重要的。下面關(guān)于反饋的三個標準是很有用的：
    · 無論什么樣的修改都應(yīng)該觸發(fā)反饋流程；
    · 反饋應(yīng)該盡快發(fā)出；
    · 交付團隊必須接收反饋，并依據(jù)它作出相應(yīng)的行動。
    讓我們逐一審視一下這三個標準，考慮如何能達到這樣的標準。
    1.3.1　每次修改都應(yīng)該觸發(fā)反饋流程
    一個可工作的軟件可分成以下幾個部分：可執(zhí)行的代碼、配置信息、運行環(huán)境和數(shù)據(jù)。如果其中任何一部分發(fā)生了變化，都可能導致軟件的行為發(fā)生變化。所以我們要能夠控制這四部分，并確保任何修改都會被驗證。
    當修改了源代碼后，可執(zhí)行代碼當然也就會隨之發(fā)生變化。因此每當修改源代碼后，都要進行構(gòu)建和測試。為了能夠控制這個流程，構(gòu)建可執(zhí)行代碼并對其進行測試都應(yīng)該是自動化的。每次提交都對應(yīng)用程序進行構(gòu)建并測試，這稱作持續(xù)集成。我們會在第3章詳細描述它。
    之后的部署活動中都應(yīng)該使用這個構(gòu)建并測試后的可執(zhí)行代碼，無論是部署至測試環(huán)境，還是生產(chǎn)環(huán)境。如果你的應(yīng)用軟件需要編譯，你應(yīng)該確保在所有需要可執(zhí)行代碼的地方都使用在構(gòu)建流程中已生成的這個，而不是再重新編譯一次生成一個新的。
    對環(huán)境的任何修改都應(yīng)該作為配置信息來管理。無論在什么環(huán)境下，對于應(yīng)用程序配置的變更都應(yīng)該被測試。如果用戶自己安裝軟件的話，任何可能的配置項都應(yīng)該在各種具有代表性的環(huán)境上測試。  配置管理將在第2章中討論。
    如果需要修改該應(yīng)用程序所要被部署的運行環(huán)境，那么整個系統(tǒng)都應(yīng)該在修改后的環(huán)境中進行測試。這包括對操作系統(tǒng)配置、該應(yīng)用程序所依賴的軟件集、網(wǎng)絡(luò)配置，以及任何基礎(chǔ)設(shè)施和外部系統(tǒng)的修改。第11章會講基礎(chǔ)設(shè)施和環(huán)境的管理，包括自動化地創(chuàng)建及維護測試環(huán)境和生產(chǎn)環(huán)境。
    如果是數(shù)據(jù)結(jié)構(gòu)發(fā)生了變化，這些變化也同樣要經(jīng)過測試。我們在第12章討論數(shù)據(jù)管理。
    什么是反饋流程？它是指完全以自動化方式盡可能地測試每一次變更。根據(jù)系統(tǒng)的不同，測試會有所不同，但通常至少包括下面的檢測。
    · 創(chuàng)建可執(zhí)行代碼的流程必須是能奏效的。這用于驗證源代碼是否符合語法。
    · 軟件的單元測試必須是成功的。這可以檢查應(yīng)用程序的行為是否與期望相同。
    · 軟件應(yīng)該滿足一定的質(zhì)量標準，比如測試覆蓋率以及其他與技術(shù)相關(guān)的度量項。
    · 軟件的功能驗收測試必須是成功的。這可以檢查應(yīng)用是否滿足業(yè)務(wù)驗收條件，交付了所期望的業(yè)務(wù)價值。
    · 軟件的非功能測試必須是成功的。這可以檢查應(yīng)用程序是否滿足用戶對性能、有效性、安全性等方面的要求。
    · 軟件必須通過了探索性測試，并給客戶以及部分用戶做過演示。這些通常在一個手工測試環(huán)境上完成。此時，產(chǎn)品負責人可能認為軟件功能還有缺失，我們自己也可能發(fā)現(xiàn)需要修復的缺陷，還要為其寫自動化測試來避免回歸測試。
    運行測試的這些環(huán)境應(yīng)該盡可能與生產(chǎn)環(huán)境相似，從而驗證對于環(huán)境的任何修改都不會影響應(yīng)用程序的正常運行。
    1.3.2　必須盡快接收反饋
    快速反饋的關(guān)鍵是自動化。對于實現(xiàn)完全自動化過程來說，唯一的約束條件就是你能夠使用的硬件數(shù)量。如果是手工過程，我們可以通過人力來完成這個工作。然而，手工操作會花更長的時間，可能引入更多的錯誤，并且無法審計。另外，持續(xù)做手工構(gòu)建、測試和部署非�？菰锒�且有重復勞動，與人力資源利用率的準則相悖。人力資源是昂貴且非常有價值的，所以我們應(yīng)該集中人力來生產(chǎn)用戶所需要的新功能，盡可能快速地交付這些新功能，而不是做枯燥且易出錯的工作。像回歸測試、虛擬機的創(chuàng)建和部署這類工作最好都由機器來完成。
    當然，實現(xiàn)這樣的部署流水線是需要大量資源的，尤其是當有了全面的自動化測試套件之后。部署流水線的關(guān)鍵目的之一就是對人力資源利用率的優(yōu)化：我們希望將人力釋放出來做更有價值的工作，將那些重復性的體力活交給機器來做。
    對于整個流水線中的提交（commit）階段，其測試應(yīng)具有如下特征。
    · 運行速度快。
    · 盡可能全面，即75%左右的代碼庫覆蓋率。只有這樣，這些測試通過以后，我們才對自己寫的軟件比較有信心。
    · 如果有測試失敗的話，就表明應(yīng)用程序有嚴重問題，無論如何都不能發(fā)布。也就是說，像檢查界面元素的顏色是否正確這類測試不應(yīng)該包含在這個測試集合當中。
    · 盡可能做到環(huán)境中立。這個環(huán)境沒必要和生產(chǎn)環(huán)境一模一樣，可以相對簡單廉價一些。
    相對而言，提交階段之后的測試一般有如下這些特點。
    · 它們通常運行更慢一些，所以適合于并行執(zhí)行。
    · 即使某些測試有可能失敗，但在某種場合下，我們還是會發(fā)布應(yīng)用程序。比如某個即將發(fā)布的版本有一個不穩(wěn)定的修復，會導致其性能低于預先定義的標準，但有時我們還是會決定發(fā)布這個版本。
    · 它們的運行環(huán)境應(yīng)該盡可能與生產(chǎn)環(huán)境相同。除了測試功能以外，它同時還會對部署過程以及對生產(chǎn)環(huán)境的任何修改進行測試。
    先經(jīng)過一輪測試（在便宜的硬件上運行最快的那些測試）之后，再經(jīng)過這種測試過程，會讓我們對軟件更有信心。如果這些測試失敗了，這個構(gòu)建版本就不會再進入后續(xù)階段，這樣就可以更好地利用資源。第5章中會詳細介紹流水線技術(shù)，而第7、8、9章中會分別講述提交測試階段、自動化驗收測試，以及非功能需求的測試。
    這種方法的基礎(chǔ)之一就是快速的反饋。為了確保對變更的快速反饋，我們就要注意開發(fā)軟件的流程，特別是如何使用版本控制系統(tǒng)和如何組織代碼。開發(fā)人員應(yīng)該頻繁提交代碼到版本控制系統(tǒng)中，像管理大規(guī)模團隊或分布式團隊那樣，將代碼分成多個組件。在大多數(shù)情況下，應(yīng)該避免使用分支。我們將在第13章討論增量式交付以及組件的使用，在第14章中討論分支與合并。
    ……