從別處看到了一篇關於持續集成的文章，個人感覺蠻不錯的，分享給大家。。。

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

1、什麽是持續集成？

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

而在軟件行業中，集成並不是一個簡單的“搬箱子”的過程。因為軟件工業是一個知識生產活動，其內在邏輯非常復雜，需求又很難一次性確定，完成的產品與最初的設計往往相差很遠。

敏捷宣言中就有一條是說響應變化重於遵循計劃。而且由於軟件行業的迅猛發展，軟件變的越來越復雜，單靠個人是根本無法完成。

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

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

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

其中一個很重要的原因就是項目集成發生的頻率太低，導致大家對項目很沒有信心。

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

在持續集成中，團隊成員頻繁集成他們的工作成果，一般每人每天至少集成一次,也可以多次。每次集成會經過自動構建(包括自動測試)的檢驗，以盡快發現集成錯誤。

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

2、持續集成能給團隊帶來什麽好處？

如果想要談持續集成的好處，那麽我們應該先談談沒有采納持續集成，項目會出現什麽問題。

總體來說，沒有采用持續集成的項目一般會面臨下面四個問題：

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

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

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

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

③、低品質的軟件。 由於集成時每次包含的代碼很多，所以大家的關註點主要都是如何保證編譯通過、自動化測試通過，而往往很容易忽略代碼是否遵守了編碼規範、是否包含有重復代碼、

是否有重構的空間等問題。而這些問題又反過來會影響今後的開發和集成，久而久之集成變得越來越困難，軟件的質量可想而知。

④、項目缺少可見性。

而通過持續集成的活動，可以實現以下價值：

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

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

③、在任何時間、任何地點生成可部署的軟件。對客戶來說，可以部署的軟件是最實際的資產；

④、增強項目的可見性。集成就像我們項目的一面鏡子，通過這面鏡子能夠快速的了解項目目前的狀況、存在的問題；

⑤、對開發團隊的軟件產品建立起更強大的信心。它能夠幫我們有效的決策，註意到項目進展的趨勢；

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

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

①、版本管理系統：項目的源代碼需要托管到適合的版本管理系統中，一般我們使用git作為版本控制庫，版本管理軟件可以使用github、gitlab、stash等。

②、構建腳本：每個項目都需要有構建腳本來實現對整個項目的自動化構建。比如Java的項目就可以使用gradle作為構建工具。

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

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

4、持續集成的全景圖是什麽樣子的？

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

5、持續集成一般都包含哪些任務？

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

拿一個Java項目為例，持續集成一般執行的任務有：

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

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

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

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

④、測試覆蓋率檢查：一般項目會有個測試覆蓋率指標（比如80%），如果代碼達不到這樣的測試覆蓋率，就不允許代碼遷入。這樣可以保證開發人員在新增功能時也要為新加入的功能編寫自動化測試。

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

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

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

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

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

因為構建成功的標準是所有的驗證都能夠通過，那麽執行時間短的任務放在前面能更快的得到反饋。

7、為什麽我們組搭建了持續集成服務器，並且還派專人看守CI，但是感覺項目並沒有明顯的改善？

並不是說搭建了持續集成服務器就說明團隊能成功運行持續集成了。持續集成是一個實踐，所以大家要遵循一些原則。

大家可以先思考一下問題：

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

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

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

從這些問題可以引申出持續集成中需要遵循的一些原則：

①、經常提交代碼

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

③、立即修復無法集成的構建

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

⑤、必須通過所有測試和審查

⑥、執行私有構建

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

8、本地提交代碼應該經過哪些步驟？

本地提交可以采用經典的七步提交法。

<轉>about持續集成，你不知道的事