您好,登錄后才能下訂單哦!
這篇文章主要講解了“Travis CI是什么”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“Travis CI是什么”吧!
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都已經是一個分布式系統了。
加入監控指標和日志是一次循序漸進的學習過程,但是最終,它們讓我們可以了解這個系統正在做什么,無論是通過圖表還是日志。
這對我們而言是一個巨大的提升。可見性對于運行一個分布式系統是非常重要的。
當你寫一個系統時,考慮好如何監控它。
做好監控會有助于你的系統更好的在生產環境運行,而不僅僅是通過測試。
關鍵是,更多的監控不僅僅是讓你可以對系統更了解,你也會發現那些你以前未曾想到或見到的問題。系統更高的可見性帶來更多的責任感。現在我們需要去面對這樣的事實:我們對系統的錯誤有了更多的了解,所以我們必須更有效的工作來減少這些錯誤所帶來的影響。
感謝各位的閱讀,以上就是“Travis CI是什么”的內容了,經過本文的學習后,相信大家對Travis CI是什么這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。