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章中討論分支與合并。

1.3.3 交付團隊必須接收反饋并作出反應(yīng)

參與軟件交付過程的所有人（包括開發(fā)人員、測試人員和運維人員、數(shù)據(jù)庫管理員、基礎(chǔ)設(shè)施的專家以及管理者）都應(yīng)該參與到這個反饋流程中，這是至關(guān)重要的。如果這些人無法做到每天都在一起工作（盡管我們認為團隊應(yīng)該是全功能團隊），就一定要常常碰頭并一起探討如何改進軟件交付的流程。對于快速交付高質(zhì)量的軟件來說，基于持續(xù)改進的過程是非常關(guān)鍵的。迭代過程有助于為這類活動建立規(guī)律性，例如每個迭代至少開一次回顧會議，在會上每個人都應(yīng)參與討論如何在下一個迭代中改進交付過程。

想要能夠根據(jù)反饋來調(diào)整行動，就要對信息進行廣播。使用一個大且可視的儀表盤（并非一定要電子的），或者其他通知機制對于確保反饋送達到每一個人是極為重要的。這個儀表盤應(yīng)該隨處可見，而且至少每個團隊的屋中都應(yīng)放置一個。

當然，如果最后沒有引發(fā)什么改進行動，反饋也就沒有什么用了。因此，這就要求紀律性和計劃性。當需要采取行動時，整個團隊有責任停下他們手中的事情，來決定接下來采取哪些行動。在完成此事之后，團隊才能繼續(xù)自己的工作。

1.3.4 這個流程可以推廣嗎

很多人認為我們所描述的過程太理想化了。他們認為，這樣的事情在小團隊中可能行得通，但在大型分布式項目中是不行的！

我們在過去的幾年中，在不同的行業(yè)里做過很多大型項目。我們非常幸運，曾與有各種不同經(jīng)驗的同事在一起工作。本書中描寫的所有技術(shù)與實踐，在各種組織（無論大型組織還是小型組織）各種情況下的真實項目中都被證明是有效的。也正是在此類項目中一次又一次經(jīng)歷同樣的問題，才促使我們寫了這本書。

你會注意到，書中的很多東西都來自于精益思想和哲學。精益制造的目標是確保快速地交付高質(zhì)量的產(chǎn)品，它聚焦于消除浪費，減少成本。多個行業(yè)的實踐已經(jīng)證明，精益制造可以節(jié)省大量成本和資源，帶來高質(zhì)量的產(chǎn)品，縮短產(chǎn)品上市時間。這一哲學在軟件開發(fā)領(lǐng)域也漸成主流，而且影響著本書中的很多內(nèi)容。精益并不僅僅局限于應(yīng)用在小系統(tǒng)上，它已在大型組織甚至整個經(jīng)濟體系中得到應(yīng)用。

根據(jù)我們的經(jīng)驗，這一理論與實踐既可以應(yīng)用在大型組織中，也可以應(yīng)用于小團隊，但我們并不要求你馬上相信我們所說的。自己試一試，就能找到答案。保留那些對你的團隊有效的實踐，放棄那些無效的實踐，將你的經(jīng)驗寫下來，以便別人可以借鑒。