記得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的方向是什麼了。
編碼 -> 建構 -> 內建 -> 測試 -> 傳遞 -> 部署
通過這張圖，我們可以看到三者擁有不同的自動化傳遞周期。
那麼，所謂的持續內建和持續傳遞（持續部署） 究竟是什麼呢？
持續內建是一種軟體開發實踐，目的是希望團隊中的成員頻繁地将代碼合并到代碼倉庫的主幹分支上，并且一旦代碼成功合并，系統就會通過自動建構應用并運作不同級别的自動化測試來驗證這些更改，進而更早更快地将問題暴露出來。将傳統開發模式中經常會出現一堆bug的代碼內建階段分散在每個工作日中，有效地降低了bug修複的難度和時間。
持續傳遞是持續內建的延伸，将內建後的代碼部署到指定環境倉庫之中(一個可随時部署到生産環境的代碼庫)，并且經過一系列的自動化流程。在流程結束時，運維團隊可以快速、輕松地将應用部署到生産環境中。
持續傳遞經常容易與持續部署混淆。持續部署意味着所有的變更都會被自動部署到生産環境中。持續傳遞意味着所有的變更都可以被部署到生産環境中。持續部署是持續傳遞的最高階段。
CI/CD提供了一個優秀的 DevOps 環境，對于整個團隊來說，好處與挑戰并行。無論如何，頻繁部署、快速傳遞以及開發測試流程自動化都将成為未來軟體工程的重要組成部分。而我們，作為未來的一部分，也要積極地學習新的技術與開發模式，積極地擁抱未來。
有需要的同學可以加我的公衆号，以後的最新的文章第一時間都在裡面，也可以找我要思維導圖