敏捷開發-持續部署（CI/CD們）
本篇帶領大家走入研發內部來看看，首先介紹下這幾個英文單詞：CI、CD、CD
CD還是重複的，介紹下他們是什麼的縮寫：
- CI----Continuous Integration（持續整合）
- CD---Continuous Deployment（持續部署）
- CD---Continuous Delivery（持續交付）
軟體開發過程上，有個很著名的模型---瀑布開發模型，如下：
主張的是一個過程節點完整走完後，再進入下一個過程節點，一個專案一個大過程。
這個過程的問題就是太大了，導致無法敏捷，並且到編碼階段轉入測試階段時，由於一次性構建了太多，這個時候想要整合，就會出現很多問題，導致測試也進行不下去，更別說交付、運營了。
後來，又引進了敏捷開發，都是用來解決大瀑布模型導致的太重問題，無法敏捷。
怎樣才能敏捷起來呢？先來分析分析大瀑布為啥就不不能敏捷呢，問題在哪？
- 大瀑布模型裡，需求一次性全部梳理清晰，所花費的時長肯定長，而且由於整個過程長度長，因此等到反映過來不是想要的，那就很麻煩了
- 分析節點裡，同樣的道理，由於分析內容多，所以容易遺漏，時間長，如果稍有問題，後面的環境再進行一放大，再去整改會更麻煩
- 編碼到測試環節裡，由於工件是需要交付的，需要部署的，然後才能進行測試。但是部署牽涉到環境配置、服務部署等，都容易出錯，因此這2個節點之前的遷移也是個麻煩事
- 測試環節裡，由於先前要花很長時間才能進行一整個的測試，可想而知，脫節比較嚴重，如果程式碼質量再不行的話，測試人員就別提有多麼痛苦了，測試這關過不了，就別提上線時間了
研發一般都是根據需求來評估以及進行日常開發行為的，是不是把需求分割小點，多批次進行開發，或者說分多個批次進行上述的瀑布模型？ 似乎行
產品經理、測試工程師，是不是也可以通過切分需求，分批次來進行需求分析、測試呢？似乎行，能敏捷嗎？可以相對快速的調整方向上的問題嗎？似乎行
scrum就是來解決這個問題的框架之一
總體思想是分批次進行開發，這樣有利於整體的敏捷性，快速響應，以及優先順序的調整（關鍵在需求如何拆分、如何管理需求、以及各環節之間如何自動化）。
打住，我們的主題CI/CD。對於scrum來說（乃至敏捷開發來說）CI/CD是個內建特性（必須項），有了CI/CD，scrum才可能敏捷，先切入CI/CD。
持續整合
持續整合上，需要落地的是怎樣把寫好的新程式碼整合到主幹上，commit後會不會導致broken、會不會導致需求意義上的broken，這些新程式碼是不是存在質量問題，是不是存在安全問題，等等。
最常見的實現方式，就是jenkins配好特性分支，針對這個特性分支進行各種管道處理，比如：sonar靜態程式碼掃描、mvn單元測試的執行、單元測試覆蓋率驗證、zab安全掃描等等。
從上面的單詞可以看出，要內建質量，CI這個過程很重要，是需要重點抓的，如：單元測試的編寫、sonar規則需要根據專案乃至公司自定義部分的配置、等保安全等等。
引申出來的地方其實挺多的，比如單元測試怎麼寫，為了寫單元測試，需要做到OO，程式碼架構也要跟著變、對於開發人員來說，要求其實高了很多很多的。
持續部署
持續部署比較容易理解，就是持續的部署程式碼到各種環境中（除了生產環境外），部署後，測試工程師過來驗證，UAT的話，使用者也會過來驗收。
現代服務一般都是微服務，code+配置+資料庫，都是需要考慮到的，code部分經過了CI步驟，可以比較平滑的部署到後續環境，但是配置、資料庫呢？其實也是需要尋找自動化工具來解決的
這裡介紹個名詞：GitOps，既：所有的變更全部進git版本控制系統中，沒有人工操作，這樣的好處是，一鍵即可構建整個環境、並且也方便了回滾，如：k8s生態圈
持續交付
持續交付，生產環境的釋出一般是很謹慎的，早期是手工釋出，手工核對的較多。但是隨著自動化能力的提高，發現自動化釋出的越多，對生產環境越順暢，人工釋出反而會導致不穩定性。
因此生產環境的自動化部署，也是門很深的學問，並不是簡單的持續部署延續。
prd釋出，需要考慮工件的版本（經過測試的工件版本，比如在prd分支下再次打包，這個行為其實是存在引入和test環境不一致因素的操作，最好的辦法是原封不動的拷貝映象，不做重複工作）；
是不是考慮api的版本化，相容性 ，以及灰度釋出，都是要考慮的。
CI/CD部分就簡要介紹到這裡，希望能帶領大家用研發的視角來看待需求的交付，當然本篇說的還只是需求交付的一部分，本篇關注於研發內部。
感謝大家的聆聽。