1. 什麼是CI/CD
持續集成
持續集成是指軟件個人研發的部分向軟件整體部分交付，頻繁進行集成以便更快地發現其中的錯誤。“持續集成”源自於極限編程(XP)，是 XP 最初的 12 種實踐之一。
CI 需要具備這些：
全面的自動化測試。這是實踐持續集成&持續部署的基礎，同時，選擇合適的自動化測試工具也極其重要;靈活的基礎設施。容器，虛擬機的存在讓開發人員和 QA 人員不必再大費周折;版本控制工具。如 Git，CVS，SVN 等;自動化的構建和軟件發佈流程的工具，如 Jenkins，flow.ci;反饋機制。如構建/測試的失敗，可以快速地反饋到相關負責人，以儘快解決達到一個更穩定的版本。
持續集成的優點
“快速失敗”，在對產品沒有風險的情況下進行測試，並快速響應;最大限度地減少風險，降低修復錯誤代碼的成本;將重複性的手工流程自動化，讓工程師更加專注於代碼;保持頻繁部署，快速生成可部署的軟件;提高項目的能見度，方便團隊成員瞭解項目的進度和成熟度;增強開發人員對軟件產品的信心，幫助建立更好的工程師文化。
持續交
持續交付在持續集成的基礎上，將集成後的代碼部署到更貼近真實運行環境的「類生產環境」(production-like environments)中。持續交付優先於整個產品生命週期的軟件部署，建立在高水平自動化持續集成之上。
試想想，如果說等到所有東西都完成了才向下個環節交付，導致所有的問題只能再最後才爆發出來，解決成本巨大甚至無法解決。比如，我們完成單元測試後，可以把代碼部署到連接數據庫的 Staging 環境中進行更多的自動化測試。如果代碼沒有問題，可以繼續手動部署到生產環境中。當然，持續交付並不是指軟件每一個改動都要儘快部署到產品環境中，它指的是任何的代碼修改都可以在任何時候實施部署。
。
持續交付和持續集成的優點非常相似：
快速發佈。能夠應對業務需求，並更快地實現軟件價值。編碼->測試->上線->交付的頻繁迭代週期縮短，同時獲得迅速反饋;高質量的軟件發佈標準。整個交付過程標準化、可重複、可靠，整個交付過程進度可視化，方便團隊人員瞭解項目成熟度;更先進的團隊協作方式。從需求分析、產品的用戶體驗到交互 設計、開發、測試、運維等角色密切協作，相比於傳統的瀑布式軟件團隊，更少浪費。
件團隊，更少浪費。
2. 為什麼使用docker
上述講到CI/CD其關鍵在於高度的自動化，除此之外，還需要有相應的容器/虛擬機技術來配合。不然，在開發環境->測試環境->生產環境等交接時，都可能出現問題。具體說下，包括以下幾點：
依賴時的複雜度
項目除了對程序包的依賴，對於運行環境也有些具體的要求。比如，Web應用需要安裝和配置Web服務器、應用服務器、數據服務器等，企業應用中可能需要消息隊列、緩存、定時作業，或是對其他系統以Web Service或API的方式暴露服務等。這些可以看成項目在系統層面對外部的依賴。這些依賴有些可以由項目自行處理，而有些則是項目無法處理的，比如運行容器，操作系統等，這些是項目的運行環境。
總
依賴包間的版本兼容性問題。兼容性問題是軟件開發者的噩夢。
間接依賴，或多重依賴問題。例如：A依賴於Python 2.7，A還依賴於B，但B卻依賴於Python 3，苦逼的是Python 2.7和Python 3不兼容。依賴中最痛苦的事莫過於此。
。依賴中最痛苦的事莫過於此。
不一致的環境
簡單項目中，開發和運行環境都由開發人員搭建，當公司變大時，系統的運行環境將由運維人員搭建，而開發測試環境如果由運維人員搭建則工作量太大，由開發人員自己搭建則操作複雜又容易產生不一致的情況。假設公司為項目A和項目B開發了新版本。但環境和軟件升級不是同步進行，出錯的可能性非常大（想一想間接依賴和多重依賴的情況）。大家對這樣的場景有沒有印象：當新版本部署時，發現問題，測試或部署人員說：“版本有問題，無法運行！”開發人員卻說：“我這裡沒問題啊，運行正常！”
氾濫的部署
如果項目簡單，沒有任何歷史項目和代碼的拖累，且各項目之間也沒有任何的關聯，只需進行資源方面的管理：分配機器，初始化系統，分配IP地址等。各個項目的運行環境、數據庫、開發環境等都由具體項目的開發人員手動完成，這樣的環境出問題怎麼辦？很簡單，涼拌——重裝系統。
理想很豐滿，現實很骨感，歷史遺留問題往往對現在的項目有很大影響：多語言（Java，PHP、C ），多系統（各種Windows、Linux），多構建工具版本（Java7、8），各種配置文件和各種黑科技補丁腳本散落在系統的各個角落，沒人能找得到，也沒人搞得懂。配置被誰改掉了，服務宕掉了，根本無從管理。
那麼開始介紹我們的docker，此處附上鍊接，就不贅述docker是什麼了。docker官網
我們來講講使用docker有什麼好處。
首先，Docker可以讓你非常容易和方便地以“容器化”的方式去部署應用。 它就像集裝箱一樣，打包了所有依賴，再在其他服務器上部署很容易，不至於換服務器後發現各種配置文件散落一地，這樣就解決了編譯時依賴和運行時依賴的問題。
其次，Docker的隔離性使得應用在運行時就像處於沙箱中，每個應用都認為自己是在系統中唯一運行的程序，就像剛才例子中，A依賴於Python 2.7，同時A還依賴於B，但B卻依賴於python 3，這樣我們可以在系統中部署一個基於Python 2.7的容器和一個基於Python 3的容器，這樣就可以很方便地在系統中部署多種不同環境來解決依賴複雜度的問題。這裡有些朋友可能會說，虛擬機也可以解決這樣的問題。誠然，虛擬化確實可以做到這一點，但是這需要硬件支持虛擬化及開啟BIOS中虛擬化相關的功能，同時還需要在系統中安裝兩套操作系統，虛擬機的出現是解決了操作系統和物理機的強耦合問題。但Docker就輕量化很多，只需內核支持，無需硬件和BIOS的強制要求，可以輕鬆迅速地在系統上部署多套不同容器環境，容器的出現解決了應用和操作系統的強耦合問題。
正因為Docker是以應用為中心，鏡像中打包了應用及應用所需的環境，一次構建，處處運行。這種特性完美解決了傳統模式下應用遷移後面臨的環境不一致問題。
同時，Docker壓根不管內部應用怎麼啟動，你自己愛咋來咋來，我們用docker start或run作為統一標準。這樣應用啟動就標準化了，不需要再根據不同應用而記憶一大串不同啟動命令。
基於Docker的特徵，現在常見的利用Docker進行持續集成的流程如下：
- 開發者提交代碼；
- 觸發鏡像構建；
- 構建鏡像上傳至私有倉庫；
- 鏡像下載至執行機器；
- 鏡像運行。
本文出處：https://blog.csdn.net/belalds/article/details/81103964
閱讀更多 物聯網開發者之家 的文章
