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都已經是一個分布式系統了。

加入監控指標和日志是一次循序漸進的學習過程，但是最終，它們讓我們可以了解這個系統正在做什么，無論是通過圖表還是日志。

這對我們而言是一個巨大的提升。可見性對于運行一個分布式系統是非常重要的。

當你寫一個系統時，考慮好如何監控它。

做好監控會有助于你的系統更好的在生產環境運行，而不僅僅是通過測試。

關鍵是，更多的監控不僅僅是讓你可以對系統更了解，你也會發現那些你以前未曾想到或見到的問題。系統更高的可見性帶來更多的責任感。現在我們需要去面對這樣的事實：我們對系統的錯誤有了更多的了解，所以我們必須更有效的工作來減少這些錯誤所帶來的影響。

原文鏈接： Mathias Meyer   
譯文鏈接： http://blog.jobbole.com/52397/