文章目錄
- 曾幾何時，研發、測試、運維各自為戰，如戰國之群雄割據，各領風騷，直至CI/CD橫空出世，縱橫捭阖，四海歸一，實作了“車同軌 書同文 行同倫”，将開發環境、測試環境、預發環境、生産環境聚于統一戰線，上傳下達，流水作業，一榮俱榮、一辱俱辱。
- 一、什麼是CI/CD
- `1.CI（Continuous Integration，持續內建）`
- `2.CD（Continuous Delivery，持續傳遞）`
- `3.CD(Continuous Deployment,持續部署)`
- `4.CICD的幾個特點`
- 二、為什麼要用CI/CD
- `1.CI`
- `2.CD`
- `3.四個名額`
- 1.傳遞時間：
- 2.部署頻率：
- 3.平均故障恢複耗時：
- 4.變更失敗率：
- 三、怎麼搭建一套CI/CD
- `PS：上面講了這麼多理論的東西，讓人覺得有點模糊、遙遠、不具體。下面是我根據CI/CD的基本理念，搭建的一套環境，裡面的項目比較簡單，在一些規劃上也不太合理，主要的目的是能夠對CI/CD有一個比較形象的了解。`
- 第1集，環境搭建
- 第2集，LNMP項目準備
- 第3集，WebHook觸發mvn打包
- 第4集，SonarQube實作CodeReview
- [第5集，build image](javascript:void(0))
- 第6集，部署到測試環境，Selenium自動測試
- 第7集，模拟版本更新，在測試環境驗證
- 第8集，部署到生産環境
- 第9集，流水線部署到測試環境
曾幾何時，研發、測試、運維各自為戰，如戰國之群雄割據，各領風騷，直至CI/CD橫空出世，縱橫捭阖，四海歸一，實作了“車同軌 書同文 行同倫”，将開發環境、測試環境、預發環境、生産環境聚于統一戰線，上傳下達，流水作業，一榮俱榮、一辱俱辱。
一、什麼是CI/CD
參考文章：
6 張圖帶你搞懂 CI/CD 流水線
1.CI（Continuous Integration，持續內建）
持續內建的重點是将各個開發人員的工作集合到一個代碼倉庫（如Gitlab）中。通常，每天都要進行幾次送出，主要目的是早發現，早更正，防患于未然，使團隊更加緊密結合，更好地協作。
持續內建的本質是要自動化測試。如果研發部不具備自動化測試的能力，持續內建怎麼做都是失敗的。
持續內建裡最重要的一點就是要推行單元測試、內建測試還有系統測試，單測是保證自己沒問題，內建測試是保證跟上下遊沒問題，系統測試是保證整個系統沒問題。
2.CD（Continuous Delivery，持續傳遞）
持續傳遞的目的是最小化部署或釋放過程中固有的摩擦。頻繁地将軟體的新版本，傳遞給品質團隊或者使用者，以供評審。如果評審通過，代碼就進入生産階段。
持續傳遞可以看作持續內建的下一步。它強調的是，不管怎麼更新，軟體是随時随地可以傳遞的。
持續傳遞裡很關鍵的一點就是我們要解決它的環境一緻性、配置一緻性。
環境一緻性
可以用Docker解決，Docker 本身就是一種标準化的東西。另外一個問題，配置是不是一緻性，是不是動靜分離。
持續傳遞是一種能力。隻有具備持續傳遞的能力，才能夠實作持續部署。
3.CD(Continuous Deployment,持續部署)
持續部署是一種更高程度的自動化，無論何時對代碼進行重大更改，都會自動進行建構/部署。
4.CICD的幾個特點
- 以提高研發效率為目标
- 緊貼實際業務
- 以人為本，盡可能将一切繁瑣的過程交給程式去執行
二、為什麼要用CI/CD
如果一個團隊缺乏統一标準的環境，再努力，也是事倍功半。而使用容器化技術、CI/CD，不僅能讓開發環境、測試環境、預發環境、生産環境保持一緻，同時也對測試和品質保證有至關重要的作用，能達到事半功倍的效果。
1.CI
開發人員每天都将自己的更改推送到主分支中進行內建，通常，這樣的操作每天都會發生很多次。從更高的視角來看，CI 能使開發者更快的發現子產品或功能中的錯誤。持續內建的整個流程如下：
1.開發者将代碼送出到項目主分支；
2.CI 伺服器檢測到更改并将最新代碼拉下來；
3.CI 伺服器編譯更改後的代碼，并給他們打個标簽；
4.CI 伺服器執行所有的單元測試、內建測試、端到端的測試； 如果上述任何階段，出現任何問題（包括測試用例失敗），整個 CI 流程将會被停止，并且将錯誤資訊發送給開發人員。
2.CD
持續互動在業界被簡稱為 CD ，是指在自動完成所有的自動化測試代碼過後，将通過的代碼進行直接部署。
從本質上來講，這是軟體釋出的最佳實踐。—— Jez Humble（譯者注：Jez Humble，被譽為「持續傳遞之父」，《DevOps 實踐指南》、《精益企業》、《持續傳遞》作者。）
持續互動包含以下幾點：
1.在所有的測試通過後，自動建立一個版本，并使用腳本，将它自動部署到你所有的環境中去（測試環境、內建環境、生産環境等）。
2.作為整個流程的最後一個步驟，你還需要運作冒煙測試，來確定你所部署的服務正在順利的運作。
3.設定監控報警，當出現問題時要第一時間通知開發者。
4.應該提供功能切換的功能，隐藏代碼的具體實作細節。 在部署過程中，所有的修改都是單獨送出的，是以由部署帶來的風險和 Bug 也會相對較少。這意味着，企業能夠根據需求，更加快速地開發并部署代碼。如果能将 CD 與容器化技術（如 Docker、k8s）配合使用，在雲平台上，甚至可以實作不停機部署,這樣開發團隊就可以在任何時間進行代碼部署。
3.四個名額
1.傳遞時間：
CI / CD 可以讓開發人員編寫的代碼直接部署到生産環境中。如果一個團隊有良好的 CI / CD 的流程時，可能隻需要幾個小時甚至是幾分鐘時間就能完成新需
求上線。 2.部署頻率：
如果能夠快速部署，小範圍部署，那麼團隊可以頻繁地進行部署，特别是那些“無關緊要”的部署。Amazon 曾公布資料表示，在他們全球所有的團隊中，平均每
11s 就會部署一次。推薦一本書《鳳凰項目—一個IT運維的傳奇故事》 3.平均故障恢複耗時：
舉個例子，如團隊中的某一個部署導緻整個系統崩潰，有可能讓整個系統停機好幾個小時。那如果這個團隊有良好的 CI / CD 的實踐，那他們可以很準确地知道
是由于哪個更改造成，知道是由哪個産品線更新引起的。或許 15 分鐘後，就能夠開發出修複程式并将其重新部署到生産環境中。 4.變更失敗率：
如果使用了 CI ，那麼所有的修改都會在你的 CI 伺服器進行內建并運作所有的單元測試，這些修改也會在與使用者環境非常接近的環境中運作，當這些變更
呈現在使用者面前時，都已經是經過了大量的測試驗證過的版本，幾乎不會出現任何隐藏的 Bug。 三、怎麼搭建一套CI/CD
PS：上面講了這麼多理論的東西，讓人覺得有點模糊、遙遠、不具體。下面是我根據CI/CD的基本理念，搭建的一套環境，裡面的項目比較簡單，在一些規劃上也不太合理，主要的目的是能夠對CI/CD有一個比較形象的了解。
PS：上面講了這麼多理論的東西，讓人覺得有點模糊、遙遠、不具體。下面是我根據CI/CD的基本理念，搭建的一套環境，裡面的項目比較簡單，在一些規劃上也不太合理，主要的目的是能夠對CI/CD有一個比較形象的了解。