Continuous Integration 持續整合,簡稱CI,我覺得是一種概念,也是一種流程上,主打建議一天應該整合超過一次,以及對應處理當整合時遇到的問題與狀況,確保頻繁合併的產出完整,因此通常會搭配自動化測試(後面的章節會再探討Testing)
一般我們在開發不論是產品還是專案,我們都會使用版本控制,常見的有SVN、Git、TFVC.....,這樣可以方便多人同時開發,基本上是必備軟體,因此鄉民們有一說:「如果該公司沒做版控,不要去 / 快淘R~」,其實版控在持續整合的目標上,是很關鍵的輔助作業。
當開發需求切細並模組化,可以交付多位工程師同時開發,或是分群分組負責,因應每次的需求分支程式碼,待開發完成後再合併至主程式,每次合併時都難免會遇到一些衝突需要解決,但是若分支分離的時間越長,修改內容差異越大,就會在合併時遇到越嚴重的衝突,分之儼然成為一條新的主線,此時就是俗稱的整合地獄,為了脫離十八層,花的時間可能多更多更多....
為了要避免進入地獄,需要縮短分支獨立的時間,也就是加快開發合併的時間,但是效率再高,還是有其極值,因此縮小每次調整的範圍,也是很重要的地方,咦?這句話是不是好像在哪裡看過?You are right!這跟敏捷是相輔相成的,但CI更專注的地方是,當提高每日的合併次數時,會面臨到對應的作業調整,例如要搭配自動化測試,包含單元測試與整合測試,以顧全整合後的結果完整,如何在這樣的流程上能減少重工與成本
圖片來源:Continuous Integration vs. Continuous Delivery vs. Continuous Deployment
上面的說明,其實已經講完了CI的目的了,但我知道很多人會跟我第一次看的時候一樣,Hmmm.....我好像有懂噢!但應該不是很懂XD
那如果條列出來,應該會比較清楚一些了!
再來,探討完CI是什麼了,我們要來看看要怎麼做到CI,主要是分為人為和系統化
參考資料、延伸閱讀:
下集預告:Continuous Delivery