## [持續集成](https://lingcoder.gitee.io/onjava8/#/book/16-Validating-Your-Code?id=%e6%8c%81%e7%bb%ad%e9%9b%86%e6%88%90) 在軟件開發的早期，人們只能一次處理一步，所以他們堅信他們總是在經歷快樂之旅，每個開發階段無縫進入下一個。這種錯覺經常被稱為軟件開發中的“瀑布流模型”。很多人告訴我瀑布流是他們的選擇方法，好像這是一個選擇工具，而不僅是一廂情愿。 在這片童話的土地上，每一步都按照指定的預計時間準時完美結束，然后下一步開始。當最后一步結束時，所有的部件都可以無縫地滑在一起，瞧，一個裝載產品誕生了！ 當然，現實中沒有事能按計劃或預計時間運作。相信它應該，然后當它不能時更加相信，只會使整件事變得更糟。否認證據不會產生好的結果。 除此之外，產品本身經常也不是對客戶有價值的事物。有時一大堆的特性完全是浪費時間，因為創造出這些特性需求的人不是客戶而是其他人。 因為受流水工作線的思路影響，所以每個開發階段都有自己的團隊。上游團隊的延期傳遞到下游團隊，當到了需要進行測試和集成的時候，這些團隊被指望趕上預期時間，當他們必然做不到時，就認為他們是“差勁的團隊成員”。不可能的時間安排和負相關的結合產生了自實現的預期：只有最絕望的開發者才會樂意做這些工作。 另外，商學院培養出的管理人員仍然被訓練成只在已有的流程上做一些改動——這些流程都是基于工業時代制造業的想法上。注重培養創造力而不是墨守成規的商學院仍然很稀有。終于一些編程領域的人們再也忍受不了這種情況并開始進行實驗。最初一些實驗叫做“極限編程”，因為它們與工業時代的思想完全不同。隨著實驗展示的結果，這些思想開始看起來像是常識。這些實驗逐漸形成了如今顯而易見的觀點——盡管非常小——即把生產可運作的產品交到客戶手中，詢問他們 (A) 是否想要它 (B) 是否喜歡它工作的方式 (C) 還希望有什么其他有用的功能特性。然后這些信息反饋給開發，從而繼續產出一個新版本。版本不斷迭代，項目最終演變成為客戶帶來真正價值的事物。 這完全顛倒了瀑布流開發的方式。你停止假設你要處理產品測試和把部署"作為最后一步"這類的事情。相反，每件事從開始到結束必須都在進行——即使一開始產品幾乎沒有任何特性。這么做對于在開發周期的早期發現更多問題有巨大的益處。此外，不是做大量宏大超前的計劃和花費時間金錢在許多無用的特性上，而是一直都能從顧客那得到反饋。當客戶不再需要其他特性時，你就完成了。這節省了大量的時間和金錢，并提高了顧客的滿意度。 有許多不同的想法導向這種方式，但是目前首要的術語叫持續集成（CI）。CI 與導向 CI 的想法之間的不同之處在于 CI 是一種獨特的機械式的過程，過程中涵蓋了這些想法；它是一種定義好的做事方式。事實上，它定義得如此明確以至于整個過程是自動化的。 當前 CI 技術的高峰是持續集成服務器。這是一臺獨立的機器或虛擬機，通常是由第三方公司托管的完全獨立的服務。這些公司通常免費提供基本服務，如果你需要額外的特性如更多的處理器或內存或者專門的工具或系統，你需要付費。CI 服務器起初是完全空白狀態，即只是可用的操作系統的最小配置。這很重要因為你可能之前在你的開發機器上安裝過一些程序，卻沒有在你的構建和部署系統中包含它。正如重構一樣，持續集成需要分布式版本管理，自動構建和自動測試系統作為基礎。通常來說，CI 服務器會綁定到你的版本控制倉庫上。當 CI 服務器發現倉庫中有改變時，就會拉取最新版本的代碼，并按照 CI 腳本中的過程處理。這包括安裝所有必要的工具和類庫（記住，CI 服務器起初只有一個干凈、基本的操作系統），所以如果過程中出現任何問題，你都可以發現它們。接著它會執行腳本中定義的構建和測試操作；通常腳本中使用的命令與人們在安裝和測試中使用的命令完全相同。如果執行成功或失敗，CI 服務器會有許多種方式匯報給你，包括在你的代碼倉庫上顯示一個簡單的標記。 使用持續集成，每次你合進倉庫時，這些改變都會被從頭到尾驗證。通過這種方式，一旦出現問題你能立即發現。甚至當你準備交付一個產品的新版本時，都不會有延遲或其他必要的額外步驟（在任何時刻都可以交付叫做持續交付）。 本書的示例代碼都是在 Travis-CI(基于 Linux 的系統) 和 AppVeyor(Windows) 上自動測試的。你可以在[Gihub倉庫](https://github.com/BruceEckel/OnJava8-Examples)上的 Readme 看到通過/失敗的標記。