<轉>聊聊持續集成

從別處看到了一篇關於持續集成的文章，我的感受蠻不錯的，分享給你們。。。

原文連接：對於持續集成實踐的常見問題解答

 

一、什麼是持續集成？

集成，就是一些孤立的事物或元素經過某種方式集中在一塊兒，產生聯繫，從而構成一個有機總體的過程。知識經濟的社會，集成已經成了很重要的一個名詞。各行各業基本都會用到集成。

而在軟件行業中，集成並非一個簡單的「搬箱子」的過程。由於軟件工業是一個知識生產活動，其內在邏輯很是複雜，需求又很難一次性肯定，完成的產品與最初的設計每每相差很遠。

敏捷宣言中就有一條是說響應變化重於遵循計劃。並且因爲軟件行業的迅猛發展，軟件變的愈來愈複雜，單靠我的是根本沒法完成。

大型軟件爲了重用及解耦，每每還須要分紅好幾個模塊，這樣集成就成了軟件開發中不可或缺的一部分。

持續集成這個詞語最先是由大名鼎鼎的Martin Fowler提出的。他在早期進行軟件行業實習的時候就發現一個問題,即集成是項目中的一個大難題。

他在英國一家軟件公司實習時，項目經理親口告訴他一個項目已經開發了好幾年了，如今正在作集成，集成已經進行了好幾個月了，每一個人都很疲憊，並不知道集成何時才能結束。

其中一個很重要的緣由就是項目集成發生的頻率過低，致使你們對項目很沒有信心。

在《持續集成》一書中，對持續集成的定義是這樣的：持續集成是一種軟件開發實踐。

在持續集成中，團隊成員頻繁集成他們的工做成果，通常每人天天至少集成一次,也能夠屢次。每次集成會通過自動構建(包括自動測試)的檢驗，以儘快發現集成錯誤。

自從在團隊中引入這樣的實踐以後，Martin Fowler發現這種方法能夠顯著減小集成引發的問題，並能夠加快團隊合做軟件開發的速度。

 

二、持續集成能給團隊帶來什麼好處？

若是想要談持續集成的好處，那麼咱們應該先談談沒有采納持續集成，項目會出現什麼問題。

整體來講，沒有采用持續集成的項目通常會面臨下面四個問題：

①、沒有一致的可部署的軟件。只有在完成集成測試、系統測試後，才能獲得可用的軟件，整個過程當中只有最後時刻才能拿到可運行軟件。集成活動不必定在一個標準的構建機器上生成，

   而是在某個開發人員的機器上構建的，那麼可能存在在其餘機器上沒法運行的問題。

②、很晚才發現缺陷，而且難以修復。實踐證實，缺陷發現的越晚，須要修復的時間和精力也就越大。從上一個可工做的軟件到發現缺陷之間可能存在不少次提交，

   而要從這些提交中找出問題並修復的成本會很大，由於開發人員須要回憶每一個提交的上下文來評估影響點。

③、低品質的軟件。 因爲集成時每次包含的代碼不少，因此你們的關注點主要都是如何保證編譯經過、自動化測試經過，而每每很容易忽略代碼是否遵照了編碼規範、是否包含有重複代碼、

   是否有重構的空間等問題。而這些問題又反過來會影響從此的開發和集成，長此以往集成變得愈來愈困難，軟件的質量可想而知。

④、項目缺乏可見性。

而經過持續集成的活動，能夠實現如下價值：

①、減小風險。缺陷的檢測和修復變得更快。軟件的健康程度能夠測量；

②、減小重複過程。讓人們有時間作更多的須要動腦筋的、更高價值的工做。經過對重要過程自動化，克服項目中某些成員對實現改進的抵制；

③、在任什麼時候間、任何地點生成可部署的軟件。對客戶來講，能夠部署的軟件是最實際的資產；

④、加強項目的可見性。集成就像咱們項目的一面鏡子，經過這面鏡子可以快速的瞭解項目目前的情況、存在的問題；

⑤、對開發團隊的軟件產品創建起更強大的信心。它可以幫咱們有效的決策，注意到項目進展的趨勢；

 

三、持續集成都包括哪些要素？

一個最小化的持續集成系統須要包含如下幾個要素：

①、版本管理系統：項目的源代碼須要託管到適合的版本管理系統中，通常咱們使用git做爲版本控制庫，版本管理軟件可使用github、gitlab、stash等。

②、構建腳本：每一個項目都須要有構建腳原本實現對整個項目的自動化構建。好比Java的項目就可使用gradle做爲構建工具。

    經過構建工具實現對編譯、靜態掃描、運行測試、樣式檢查、打包、發佈等活動串起來，能夠經過命令行自動執行。

③、CI服務器：CI服務器能夠檢測項目中的代碼變更，並及時的經過構建機器運行構建腳本，並將集成結果經過某種方式反饋給團隊成員。

 

四、持續集成的全景圖是什麼樣子的？

如下是持續集成的一個全景圖。從中能夠看到咱們須要版本管理系統、構建腳本、CI服務器、CI構建機器、反饋機制。

 

五、持續集成通常都包含哪些任務？

持續集成並非說只要代碼能編譯經過就是集成成功，咱們已經把每次集成都看作一次完整的測試。任何遷入到代碼庫中的代碼都應該是能夠部署到產品環境的。

拿一個Java項目爲例，持續集成通常執行的任務有：

①、代碼靜態掃描：經過靜態掃描肯定代碼的一些潛在bug，好比未被使用的變量等。

②、代碼樣式檢查：團隊一致定義出須要遵循的編碼規範，並經過一些插件對遷入的代碼進行樣式合規性檢查，防止不守規範的代碼進入版本庫。

    好比方法名首字母小寫、類的首字母大寫、if關鍵字後面須要加空格等問題均可以歸入到樣式檢查中。

③、單元測試、集成測試、系統測試：經過運行自動化的單元測試、集成測試、系統測試能夠有效的保證遷入代碼的質量。一旦有測試失敗，開發人員就須要快速反應進行修復。

④、測試覆蓋率檢查：通常項目會有個測試覆蓋率指標（好比80%），若是代碼達不到這樣的測試覆蓋率，就不容許代碼遷入。這樣能夠保證開發人員在新增功能時也要爲新加入的功能編寫自動化測試。

⑤、編譯打包：確保沒有任何語法錯誤，生成構建產出物。

⑥、發佈: 將經過完整構建的產出物放置到產出物倉庫，以便進行後續部署。

這些任務都必須是能經過命令行自動完成的，不一樣類型的項目任務略有不一樣。

 

六、持續集成這些任務應該遵循什麼順序？

其中有一個重要的原則就是fail fast，即快速失敗。通常會把運行時間短的、價值大的任務放在前面，而運行時間長的任務放置到後面。

由於構建成功的標準是全部的驗證都可以經過，那麼執行時間短的任務放在前面能更快的獲得反饋。

 

七、爲何咱們組搭建了持續集成服務器，而且還派專人看守CI，可是感受項目並無明顯的改善？

並非說搭建了持續集成服務器就說明團隊能成功運行持續集成了。持續集成是一個實踐，因此你們要遵循一些原則。

你們能夠先思考一下問題：

①、在CI服務器上多久會看到一次集成？

②、CI服務器的集成結果是綠色居多（指構建成功）仍是紅色居多（指構建失敗）？

③、當構建失敗後，團隊成員有沒有第一時間修復構建，有沒有在構建失敗的狀況下依然在提交代碼，在提交代碼以前有沒有進行本地的私有構建？

從這些問題能夠引伸出持續集成中須要遵循的一些原則：

①、常常提交代碼

②、不要提交沒法構建的代碼

③、當即修復沒法集成的構建

④、編寫自動化的開發者測試

⑤、必須經過全部測試和審查

⑥、執行私有構建

⑦、避免遷出沒法構建的代碼

 

八、本地提交代碼應該通過哪些步驟？

本地提交能夠採用經典的七步提交法。