持續(xù)集成
開發(fā)中，我們經(jīng)常遇到一些奇怪的問題，比如本地可以編譯成功的代碼但是同事們更新代碼后編譯出錯，或者在項目有多個target的時候，資源文件只添加到了當前的target，另外一個target這個時候是不能正常編譯的，再比如寫的工具類，被同事改了，或者自己有所改動很多地方用到了，怎么保證這個類的行為沒有發(fā)生變化而影響到項目中的其他模塊呢？諸如此類
那么這些問題原因在哪呢，可否避免呢？當然是可以避免的，如果代碼有新的改動，提交到版本庫中的時候，有一個人幫我們檢查必要事項，然后做做測試不就好了，這個當然是可以的，前提是老板同意專門招一個這樣的人。
引起各種奇怪問題的原因有很多，比如開發(fā)環(huán)境比較復雜不干凈，IDE的bug，提交前有一些必要的檢查需要做，但是開發(fā)時因為各種原因沒做，這些機械重復的事情我們可以找一個工具來幫我們做，而且這個工具跑在一個專門的服務器上，該服務器環(huán)境相對干凈，可以運行一些自動化操作，而自動編譯，代碼檢查，測試等環(huán)節(jié)，那么這種東西，解釋接下來講的持續(xù)集成。
持續(xù)集成是什么？
持續(xù)集成是一種軟件開發(fā)實踐，即團隊開發(fā)成員經(jīng)常集成他們的工作，通常每個成員每天至少集成一次，也就意味著每天可能發(fā)生很多次集成，每次的集成都通過自動化的構建(包括編譯，發(fā)布，自動化測試)來驗證，從而盡早發(fā)現(xiàn)集成錯誤，簡單來說，就是持續(xù)的定時的再多個團隊成員的工作中進行集成，并且給予反饋。
持續(xù)集成需要開發(fā)人員一天多次的將代碼集成到主干，并進行自動化編譯，測試等操作，由于這種頻繁集成，以及集成后及時開始的編譯和測試，可以有效避免我們在提交代碼時沒有進行必要檢查而導致的錯誤，以及一些超出預期效果的更改，從而保證代碼的質量。
由于這種及時性，如果在一次提交后項目集成失敗，可以快速的在這次提交中查找問題所在，縮小了找問題的范圍，從而減少了一些debug的時間。同時如果按照這種實踐，那么我們的主干代碼時刻都是正確的，這樣我們可以更頻繁的交付。
為什么要用持續(xù)集成？
一般規(guī)模較小的項目，對外部系統(tǒng)的依賴和服務調用很小，對于軟件的集成不是問題，但是隨著軟件復雜度的增加，對集成提成了更多的要求，持續(xù)集成的好處就提現(xiàn)出來了。
- 對重復的編譯發(fā)布等操作進行抽象，減少重復過程。
- 及時發(fā)現(xiàn)各種沖突和錯誤，減少風險。
- 任何時間，任何地點生成可部署的軟件
- 開發(fā)人員和運維人員都減輕了工作負擔
持續(xù)集成怎么做？
基本要求：要將這種實踐付諸實際，需要一些必備的條件，如下：
- 一個自動構建過程，包括自動編譯、分發(fā)、部署和測試等。
- 一個代碼倉庫，即需要版本控制軟件來保障代碼的可維護性，同時作為構建過程中的其中一個素材。
- 一個持續(xù)集成服務器。
自動化構建過程，可幫助我們節(jié)省大量時間，完成這個過程的自動化后，在以后的開發(fā)中，我們需要做的，只是提交代碼到版本庫中，構建自動完成，基本不再需要人工干預。
代碼倉庫作為構建的素材庫，構建所需的代碼從代碼庫中獲得。
最好有一臺服務器單獨作為持續(xù)集成服務器，一方面保證了環(huán)境的純凈，一方面不影響開發(fā)，而且持續(xù)集成服務器一般都是隨時準備開始構建的，所以一般也不會關機。
首先要有統(tǒng)一的代碼庫，持續(xù)集成服務器按一定頻率(或者使用鉤子)從版本控制服務器(代碼庫)上檢查代碼是否有更新。如果發(fā)現(xiàn)有代碼更新，那么就從版本控制服務器上下載最新的代碼，等代碼完全更新以后，調用自動化比編譯腳本(maven項目下的pom.xml文件)，進行代碼編譯。然后運行所有的自動化測試，并且進行代碼分析。如果其中任何一個步驟失敗，就表示build失敗，持續(xù)集成服務器會給予響應的反饋。每次提交代碼之后，都會在持續(xù)集成服務器上觸發(fā)一個定時構建，然后進行編譯部署。
大致的流程圖，便于理解：
測試環(huán)境：
- 開發(fā)人員將代碼上傳至Git服務器
- Jenkins持續(xù)集成服務器拉取Git上的代碼并配合maven將項目自動構建成war包或jar包
- 通過shell腳本自動發(fā)布項目到測試服務器
生產(chǎn)環(huán)境：
測試環(huán)境將項目測試沒問題后，將項目推送到線上正式環(huán)境。關于自動推送到線上環(huán)境又有一套嚴密的流程。
備注：有時候我們在測試環(huán)境經(jīng)過仔細的測試后沒問題后推送到線上環(huán)境，但是依然會出現(xiàn)問題，有時是測試問題，有時是無法完全模擬線上環(huán)境問題(調用第三方需要認證的接口除外，如支付接口等)，那么這時候我們就可以考慮上docker了。保證了環(huán)境的一致性的同時又可以做到完整的鏡像版本迭代。
