這一篇文章是作為開場白簡單說一下個人對持續整合的一點認識，也算是為下一篇介紹具體的實現方案做個鋪墊，不足之處還望指正。

CI概念

CI和CD(持續部署)一般是一起出現的，個人理解，持續整合就是為持續部署服務的，原來的開發模式可以總結成下面的圖(畫工比較爛)

像上圖，一個專案開始，開發人員開發自測完成後交由運維部署，然後測試，發現bug之後就會重複執行這一過程，這一過程的缺點如下：

• Bug總是在最後才出現。
• 程式經常需要變更，手動整合十分頻繁，會耗費很多時間，尤其是當前軟體開發需要產品快速產出，使用原來開發流程的不足就顯得更加明顯
• 無效的等待變多，浪費大量時間，開發在等待整合其他人的模組，測試人員在等待開發修復Bug，產品經理在等待新版本上線給客戶做演示，專案經理在等待其他人提交程式碼。
  基於上述問題，CI應運而生：
  
  在軟體工程中，持續整合（CI）是指將所有開發者的工作副本每天多次合併到主幹的做法。
  使用CI的好處：
• 解放了重複性勞動。自動化整合可以解放整合等重複性勞動，而藉助機器整合的效明顯比手工高很多，從而實現高頻次的持續整合
• 更快地修復問題。持續整合可以更早的獲取變更，更快進入測試，從而更早的發現問題
• 減少人工頻繁操作造成的失誤。一旦需要執行的重複性操作過多，人工手動操作難免就會出現錯誤，而對機器而言，只要告訴它怎麼做就OK了，出錯的機率極小
• 減少了等待時間。採用持續整合縮短了軟體開發各個環節的時間，從而也就縮短了中間可以出現的等待時機。換句話說，使用持續整合就意味著開發、整合、測試、部署等各個開發環節也得以持續。
• 更快完成產品交付。正因為使用持續整合可以減少各個開發環節的等待時間，所以可以保證產品的儘快交付與產品迭代
• 更高的產品質量。一方面持續整合伺服器可以提供程式碼規範檢查等功能，可以保證程式碼質量，另一方面，因為節約時間成本，就可以將更多的注意力放在提高產品質量上

實踐

• 可以實現程式碼頻繁提交，一種方式是使用gitlab內建GitLab-CI搭配Runner實現(會在下一篇講到)，當代碼完成推送時會自動進行整合
• 整合過程視覺化，通過上述方式實現持續整合，使得整合結果視覺化，通過命令視窗可以看到整合的每一個過程與最終結果，並且可以通過配置，將失敗結果傳送給相關人員
• 更早的發現整合錯誤，在整合伺服器上執行構建的過程中，就可以及早發現已經存在的整合錯誤

by Relon