【進階之路】持續整合、持續交付與持續部署（CI/CD）
由來
記得7月份剛剛換工作的時候，中午和老大一起去吃飯，回來的路上老大問我：“南橘，CI/CD有沒有研究過？”
我隱隱約約在哪裡聽過這個名詞，但是又想不起來，秉著實事求是的態度，我斬釘截鐵的說：“老大，我不知道CI/CD是個啥。”
老大當即對誠實的我進行了一頓誇耀，並且高興地獎勵我回去研究CI/CD的機會，並且告訴我，我們team的ScrumMaster馬上要入職了，加下來的工作會採取持續整合(CI)和持續交付( 持續部署)(CD) 的模式。
沒過幾天，新的ScrumMaster(就叫他S哥)就來了，專案也準備開始了。經過前期對需求的反覆熟悉，我一下子就新建了好幾個工程檔案，正準備摩拳擦掌展露自己的實力的時候，S哥趕緊攔住了我：“不急，我們先玩一個遊戲”。
接下來，S哥組織了整個Team成員對水果從口感、大小、外形、方便程度等各個方面進行打分，並且只要有人的分數與平均分不一致，就需要闡述自己的理由。這個方法很棒，一邊讓我們知道了各個同事的口味，一邊也讓我們理解了實現CI/CD中的重要前提：任務拆分。
任務拆分
舉個例子，在進行CI/CD的過程中，有一項任務是每天的例會（Daily meetings.）。大家快速交代自己昨天任務的完成情況，如果有問題，就在這裡提出來，尋找相應的支援或者共同探討。一方面可以提高工作的效率，另一方面也大大減少了划水摸魚的情況。而要實現每天都有能分享的東西而不是發表一些類似於“昨天寫程式碼，今天寫程式碼，明天還是寫程式碼”的發言，任務拆分
在一個API的前期開發中，大體上可以分為：
- 1、專案git搭建
- 2、技術文件編寫
- 3、程式碼編寫
- 4、測試用例編寫
- 5、unitTest
- 6、Sit環境搭建
- 7、程式碼review
- 8、jenkins自動整合環境搭建
- 9、AC校驗
- 10、上下游聯調
- 11、auto測試搭建
- 12、整合校驗搭建
- ...
當然，真正開發的時候可劃分的任務會更加細緻與更加貼近業務。
這個時候，之前玩遊戲建立起的默契就可以放在這裡對任務進行打分了。比如，我們統一以“專案git搭建”為基準點1分，以“程式碼review”為基準點8分，高於8分的任務繼續拆分，比如程式碼編寫這個環節大家給出了13分，那麼按照斐波那契額數列的就需要拆分成5分和8分兩個任務，並分配給相應的開發人員進行開發。
至此，將一個週期內所有需要進行的工作拆分成不同分值的任務，再根據前幾個週期的完成情況合理的規劃未來每個週期可以完成的任務。這樣，通過任務拆分，對於專案組的開發能力就有了一個合理的評判標準，不會因為任務過多導致加班加點，也不會因為任務太輕導致瘋狂摸魚，並且為更好更快的釋出產品，實現敏捷開發打下了基礎。
敏捷開發
CI/CD就是實現敏捷開發的一種方式
什麼是敏捷開發？我們都知道，網際網路行業卷，網際網路行業快，今天出需求，明天就上線是一種常態，而敏捷開發就是推動這個常態形成的助力。
敏捷開發的核心就是擁抱變化與快速迭代。
敏捷開發並不追求前期完美的設計、完美編碼，而是力求在很短的週期內開發出產品的核心功能，儘早釋出出可用的版本。然後在後續的生產週期內，按照新需求不斷迭代升級，完善產品。
用一個廣為流傳的圖片來體現敏捷開發和傳統開發模式的區別：
那我們知道了什麼是敏捷開發，也就知道CI/CD的方向是什麼了。
CI/CD
編碼 -> 構建 -> 整合 -> 測試 -> 交付 -> 部署
通過這張圖，我們可以看到三者擁有不同的自動化交付週期。
那麼，所謂的持續整合和持續交付（持續部署） 究竟是什麼呢？
持續整合是一種軟體開發實踐，目的是希望團隊中的成員頻繁地將程式碼合併到程式碼倉庫的主幹分支上，並且一旦程式碼成功合併，系統就會通過自動構建應用並執行不同級別的自動化測試來驗證這些更改，從而更早更快地將問題暴露出來。將傳統開發模式中經常會出現一堆bug的程式碼整合階段分散在每個工作日中，有效地降低了bug修復的難度和時間。
持續交付是持續整合的延伸，將整合後的程式碼部署到指定環境倉庫之中(一個可隨時部署到生產環境的程式碼庫)，並且經過一系列的自動化流程。在流程結束時，運維團隊可以快速、輕鬆地將應用部署到生產環境中。
持續交付經常容易與持續部署混淆。持續部署意味著所有的變更都會被自動部署到生產環境中。持續交付意味著所有的變更都可以被部署到生產環境中。持續部署是持續交付的最高階段。
CI/CD提供了一個優秀的 DevOps 環境，對於整個團隊來說，好處與挑戰並行。無論如何，頻繁部署、快速交付以及開發測試流程自動化都將成為未來軟體工程的重要組成部分。而我們，作為未來的一部分，也要積極地學習新的技術與開發模式，積極地擁抱未來。
有需要的同學可以加我的公眾號，以後的最新的文章第一時間都在裡面，也可以找我要思維導圖