1.4 收效

對于前面我們講到的這種方法，其主要收益是創建了一個發布流程，這個流程是可重復的、可靠的且可預見的，從而大大縮短了發布周期，使新增功能和缺陷修復能更早與用戶見面。節省下來的成本將不僅僅是金錢，還包括建立和維護這樣一個發布系統所需要的時間投入。

除此之外，還有其他一些收益，雖然其中一些我們應該能夠預見到，但另一些很可能是我們無法預測的，但一旦被發現，可以給我們帶來驚喜。

1.4.1 授權團隊

部署流水線的一個關鍵點是，它是一個“拉動”（pull）系統，它使測試人員、運維人員或支持服務人員能夠做到自服務，即他們可以自行決定將哪個版本的應用程序部署到哪個環境中。根據我們的經驗，對縮短發布周期的主要貢獻者是那些在整個交付流程中，等待拿到應用程序的某個“好”版本的人。為了得到一個可用的版本，通常需要很多的電子郵件溝通、問題跟蹤單，以及其他效率不高的溝通方式。假如是分布式交付團隊的話，這一點就成了主要的低效之源。然而實現了部署流水線之后，這個問題就徹底解決了，因為每個人都能看到應該拿哪個版本部署到相應的環境中，而且只需要單擊按鈕就能完成部署。

我們常常看到在不同的環境中運行著不同的版本，而不同角色的人工作在其上。能夠輕松地將任意版本的軟件部署到任意環境的能力能帶來很多好處。

? 測試人員可以選擇性地部署較舊的版本，以驗證新版本上的功能變化。

? 技術支持人員可以自己部署某個已發布的版本，用于重現缺陷。

? 作為災難恢復手段，運維人員可以自己選一個已知的正確版本，將其部署到生產環境中。

? 發布方式也變成一鍵式的了。

我們的部署工具為他們提供的靈活性，改變了他們的工作方式，能讓其變得更美好。總而言之，團隊成員可以更好地控制工作節奏，從而改進工作質量，這就會讓應用程序的質量得以提高。他們之間的協作更加有效，無用的交互更少，可以更高效地工作，因為不需要花太多的時間等待可用的版本。

1.4.2 減少錯誤

我們可能從方方面面將錯誤引入到軟件中。最初委托制作這個軟件的人就可能出錯，比如提出錯誤的需求。需求分析人員可能將需求理解錯了，開發人員也可能寫出了到處都是缺陷的程序，而我們在這里要說的錯誤是指由不良好的配置管理引入到生產環境的錯誤。我們將在第2章詳細闡述配置管理。現在，讓我們想一下到底需要哪些東西才可以讓一個應用程序正確地工作，當然肯定需要正確版本的代碼，除此之外呢？我們還需要數據庫模式（schema）的正確版本、負載均衡器的正確配置信息、應用程序所依賴的Web服務（比如用于查閱價格的Web服務）的正確URL等。當我們說配置管理時，指的是讓你識別并控制一組完整信息的流程與機制，這些信息包括每個字節和比特。

現在的軟件系統常常是由幾GB的內容組成，沒有哪個團隊或個人能夠在沒有機器幫助的情況下，輕松地查出這種大規模軟件中的一小處不同。與其等到問題發生，為什么不利用機器的輔助作用在第一時間防止它發生呢？

通過積極地管理在版本控制庫中的所有可能變動的內容，比如配置文件、創建數據庫及其模式的腳本、構建腳本、測試用具，甚至開發環境和操作系統的配置，我們讓計算機來做它們擅長的所有事情，即確保所用的比特和字節都在它們應該在的位置上，至少確保在代碼將要運行時確實如此。

根據我們的經驗，這種依賴手工的配置管理很常見。在我們所參與項目的很多客戶組織中，這些都是在生產環境和測試環境中實際發生的事情。一般來說，服務器A的連接池限數為100，而B的限數是120，這類問題通常并不打緊，但某些時候卻是至關重要的。

你絕對不想在業務交易最忙的時段里有突發事故，更不想發現它是由于配置項的不一致性導致的。這種情況通常發生在那些用于指定軟件運行環境的配置項上，而且這種配置信息實際上經常通過代碼指定新的執行路徑。我們必須考慮到這類配置信息的更改，并且需要像對待代碼一樣，對代碼運行的環境進行良好的定義與控制。假如我們能夠接觸到你的數據庫配置、應用服務器或Web服務器的話，肯定可以讓你的應用程序更快出故障，而且比直接修改你的編譯器或源代碼來得更快更容易。

假如這類配置參數都是由手工配置和管理的話，難免會在那種重復性的工作中出現人為錯誤。在一些重要的位置上，只要一個簡單的輸入失誤就可以讓應用程序停止運行。編程語言可以通過語法檢查來發現編譯問題，單元測試可以驗證代碼中有沒有輸入錯誤。可是很少有哪種檢查方式可以用于配置信息的驗證，尤其是當這些配置信息是在某個控制臺上直接輸入的時候。

所以，請將配置信息放在版本控制系統中。這個最簡單的動作就是一個巨大的進步。至少當你不小心修改了配置信息，版本控制系統會提醒你。這就至少消除了一種非常常見的錯誤源。

當所有的配置信息都放在版本控制系統中以后，接下來就要消除“中間人”了，即讓計算機直接使用這些配置信息，而不是再通過手工輸入的方式來進行軟件配置。雖然某些技術相對來說更順應這種方式，但是當你（通常是基礎設施提供商）仔細思考一下如何管理這類配置信息，尤其是那些最難駕馭的第三方系統的配置信息時，會驚奇地發現還有很長的路要走。我們將在第4章詳細討論相關內容，而更深入的討論將在第11章進行。

1.4.3 緩解壓力

明顯的好處中，可以緩解壓力是最吸引所有與發布相關的人的一點。絕大多數經歷過項目發布的人都會認為，當項目越臨近發布日期，就越能感覺到壓力。根據我們的經驗，壓力本身就是問題的根源所在。一些敏感、保守且具有質量意識的項目經理常常對開發人員說：“都這個時候了，你就不能直接修改一下代碼嗎？”或者讓數據庫管理員把他們并不清楚來路的數據錄入到應用程序的數據庫表中。像以上兩種情況，或者其他許多類似的情況下，其壓力是通過傳達“只要讓它可以工作就行了”這一信息表現出來的。

不要誤解，我們也遇到過同樣的事情。我們并不是說這種處理方式一定是錯誤的，如果剛把代碼部署到了生產環境中，而你的組織因為它的某個缺陷遭受經濟上的損害時，任何阻止這種損害的行為都是可以理解的。

我們的不同觀點在于，上面所提到的為了讓剛部署的產品環境可以正常運行的這兩種快速修補并不一定是業務需要使然，而更多的可能是由于“今天是計劃已久的發布日期”所帶來的壓力導致的。這里的問題在于系統上線是一個非常重大的事件。只要這是事實，就會有很多的慶典和緊張氣氛。

現在，讓我們來設想一下。如果接下來的發布只需要單擊一下按鈕，而且只需要等上幾分鐘，甚至幾秒鐘內就可以完成。另外，假如發生了非常糟糕的事情，你只要花上相同的幾分鐘或幾秒鐘的時間就可以把剛部署的內容恢復到從前的老樣子。再大膽地設想一下，假如你的軟件發布周期總是很短，那么當前生產環境中的版本與新版本之間的差異應該非常小。如果上述設想都是事實的話，那么發布的風險一定會大大降低，那種將職業生涯壓注在發布是否成功的不爽感覺也將大大減少。

對于很少的一部分項目來說，這種理想狀態可能很難成為現實。然而，對于大多數項目來說，盡管可能需要花上一些精力，但肯定是可以做到的。減少壓力的關鍵在于擁有一個我們前面所描述的自動化部署過程，并頻繁地運行它，當部署失敗后還能夠快速恢復到原來狀態。盡管剛開始做自動化時可能會很痛苦，但它會漸漸地變得容易起來，而它給項目和團隊帶來的好處是不可限量的。

1.4.4 部署的靈活性

在一個全新環境上運行應用程序應該是相當簡單的事。理想情況下，只要安裝機器或虛擬鏡像，然后配置一些與具體運行環境相關的特定選項。然后，你就可以使用自動化過程準備好新的部署環境，并選擇指定的應用程序版本進行部署。

1.4.5 多加練習，使其完美

在所參與的項目中，我們都會設法讓每個開發人員都擁有自己的專屬開發環境。但是，即使在那些做不到這一點的項目中，使用持續集成或迭代增量開發的團隊也要頻繁地部署應用程序。

最好的策略就是無論部署到什么樣的目標環境，都使用相同的部署方法。不應該有特殊的QA部署策略，或者一個特殊的驗收測試或生產部署策略。在每次以同一種方式部署應用軟件時，也是驗證我們的部署機制是否正確的時機。事實上，向其他任何環境的任何一次部署過程都是生產環境部署的一次演練。

只有一種環境可以有多變性，那就是開發環境。開發人員應該在自己的開發環境中自行生成二進制文件，而不需要在別處構建生成。所以，對這種開發環境的部署流程要求太嚴格是沒有必要的。雖然我們能夠做到在開發人員的開發機器上也以同樣的方式部署軟件，但實際上對開發環境的部署沒有必要嚴格要求。