上文我們主要介紹了雲原生的由來、定義及CNCF基金會，第二部分我們來講DevOps與CI/CD。
DevOps
DevOps（Development & Operations，開發和運維）是09年提出來的概念，但一直沒有太火。直到14年，容器與微服務架構的提出，DevOps纔得到了快速的發展。DevOps不單是一個實現自動化的工具鏈，而是組織、流程與技術的結合。組織上強調全棧團隊、團隊特性專一、團隊自治；技術上打通開發與運維；流程上強調端到端、可視化、灰度升級、A/B測試等。
對於DevOps，微服務不是必須的，但微服務爲DevOps提供了最好的架構支撐，對於組織和流程的要求也是一致的。所以，也有人稱微服務是DevOps架構。
DevOps與下面提到的CI、CD不同，DevOps更偏向於一種對於文化氛圍的構建。DevOps也即是促使開發人員與運維人員之間相互協作的文化。DevOps的概念似乎與持續交付的概念有些類似，兩者均旨在促進開發與運維之間的協作，但是實際上兩者差別很大：DevOps 更偏向於一種文化的構建，在DevOps文化指導下，團隊中將包含了具有不同技能的人員（開發、測試等），並通過自動化測試與發佈的手段，更快、更高質量的生產軟件。
持續集成
持續集成（CONTINUOUS INTEGRATION，CI）指的是開發人員頻繁的（一天多次的）將所有開發者的工作合併到主幹上。這些新提交在最終合併到主線之前，都需要通過編譯和自動化測試流進行驗證，以保障所有的提交在合併主幹之後的質量問題，對可能出現的一些問題進行預警。持續集成的核心在於確保新增的代碼能夠與原先代碼正確的集成。
持續集成帶來的好處是：
• 易於定位錯誤
• 易於控制開發流程
• 易於Code Review
• 易於減少不必要的工作
持續交付
與持續集成相比，持續交付（CONTINUOUS DELIVERY，CD）的側重點在於交付，其核心對象不在於代碼，而在於可交付的產物。由於持續集成僅僅針對於新舊代碼的集成過程執行了一定的測試，其變動到持續交付後還需要一些額外的流程。與持續集成相比較，持續交付添加了測試Test->模擬Staging->生產Production的流程，也就是爲新增的代碼添加了一個保證：確保新增的代碼在生產環境中是可用的。
持續交付帶來的好處是：
• 繁瑣的部署工作沒有了。團隊不再需要花費幾天的時間去準備一個發佈
• 可以更快的進行交付，這樣就加快了與客戶之間的反饋環
• 輕鬆應對小變更，加速迭代
持續部署
持續部署（CONTINUOUS DEPLOYMENT）指的是通過自動化部署的手段將軟件功能頻繁的進行交付。與持續交付以及持續集成相比，持續部署強調了通過自動部署的手段，對新的軟件功能進行集成。同持續交付相比持續集成的區別體現在對生產的自動化。從開發人員提交代碼到編譯、測試、部署的全流程不需要人工的干預，完全通過自動化的方式執行。這一策略加快了代碼提交到功能上線的速度，保證新的功能能夠第一時間部署到生產環境並被使用。
持續部署帶來的好處是：
• 發佈頻率更快，因爲不需要停下來等待發布。每一處提交都會自動觸發發佈流
• 在小批量發佈的時候，風險降低了，發現問題可以很輕鬆的修復
• 客戶每天都可以看到持續改進和提升，而不是每個月或者每季度，或者每年
自動實時的部署上線，是最優的解決辦法，但持續部署的要求是團隊非常成熟，並且上線前是需要經過QA測試的，所以實際情況下很難實現，一般的團隊也很難接受，挑戰和風險都很大。
我們總結下，DevOps、持續集成、持續交付、持續部署並不是某種技術棧或者框架，而是開發文化、流程、理念和操作方式。下一部分，我們將介紹雲原生最重要的概念之一：微服務。
下一期內容爲《雲原生時代（三）：微服務、API管理與集成》
參考文檔：
本文的部分內容參考或者引用以下文章，在此表示感謝，如果有涉及知識產權的問題，請聯繫我及時修改。