Travis CI 一開始僅僅是個想法，在當時甚至還有些理想化。在這個專案啟動之前，開源社群還沒有一個可用的持續整合系統。
隨著作為開源協作平臺的Github越來越被人認可，Github也非常需要可以持續對貢獻程式碼進行測試的服務，來保證一個開源專案始終處於穩定健康的狀態。
Travis CI開始於2011年初，而且很快得到了一些試用客戶。到了2011年夏天，我們每天進行700次構建。所有這些構建都是在一臺構建伺服器上進行的。Travis CI跟Github完美整合，目前Github還是Travis CI的主要平臺。
Travis CI在持續整合領域並沒有驚天動地的大動作，但它的確重新定義了一些原有的概念，並增加了一些新的想法。其中一個就是你可以在你的測試執行過程中，接近實時的看這個專案的構建日誌流。
最重要的一點，Travis CI允許你通過原始碼裡的檔案(.travis.yml)來對構建過程進行配置，而不是複雜的使用者介面。
Travis CI一開始的架構很簡單。通過Web元件可以讓專案和它的構建過程可見，同時，只要一個新的commit提交到了專案，Travis CI就可以接收到來自Github的訊息，從而觸發構建。
另外一個叫做hub的元件，是負責處理新的提交，將他們轉化成一次構建，並且處理構建任務執行和結束時產生的結果資料。
這兩個元件都是跟PostgreSQL資料庫打交道。
第三部分就是用來控制構建任務本身的執行緒集合，它們可以用來在虛擬機器例項上執行一系列的命令。
本質上，hub會顯得比其他部分稍微複雜一些。當hub處理構建日誌時，它需要與RabbitMQ進行訊息傳遞。日誌會以chunks流的形式從控制構建任務的執行緒中得到。
Hub更新資料庫中的日誌和構建結果資訊，並且hub推送他們到Pusher。通過Pusher，Travis CI可以在構建開始或結束的時候更新使用者介面。
這樣的架構一直維持到了2012年，當時我們每天進行7000個構建任務。我們欣喜的看到Travis CI在開源社群越來越廣泛的使用，並且開始支援11種語言，包括PHP，Python，Perl，Java 和 Erlang。
隨著越來越多的使用，Travis CI越來越像是一個開源專案的必備服務了。但是不幸的是，這個系統從一開始構建的時候就沒有考慮過監控。
過去，總是來自社群的使用者通知我們系統沒有正常執行，構建任務遇到異常，或是任務資訊沒有被處理好。
那可真是令人尷尬。我們的第一個挑戰就是給系統增加監控，資料指標和日誌，讓Travis CI從一個業務愛好的專案轉變為一個重要的商業平臺。我們準備釋出Travis CI的正式生產版本。
被使用者告知系統沒有正常執行直到今天仍然是我最大的噩夢，我們不得不努力工作建設好資料監控，以使系統能夠在出現問題的一開始就及時通知。
如果沒有任何資料記錄或者良好的日誌，我們根本不可能去搞清我們這個小分散式系統到底發生了什麼。無論是從哪個方面看，Travis CI都已經是一個分散式系統了。
加入監控指標和日誌是一次循序漸進的學習過程，但是最終，它們讓我們可以瞭解這個系統正在做什麼，無論是通過圖表還是日誌。
這對我們而言是一個巨大的提升。可見性對於執行一個分散式系統是非常重要的。
當你寫一個系統時，考慮好如何監控它。
做好監控會有助於你的系統更好的在生產環境執行，而不僅僅是通過測試。
關鍵是，更多的監控不僅僅是讓你可以對系統更瞭解，你也會發現那些你以前未曾想到或見到的問題。系統更高的可見性帶來更多的責任感。現在我們需要去面對這樣的事實：我們對系統的錯誤有了更多的瞭解，所以我們必須更有效的工作來減少這些錯誤所帶來的影響。