在軟件的編譯發佈的過程中，經常能夠看到CI、CD這樣的詞語。其實他們是專業的縮寫短語，這裏介紹下他們的概念和區別。
敏捷軟件開發
敏捷軟件開發，英文全稱：Agile software development，是從1990年代開始逐漸引起廣泛關注的新型軟件開發方式，是一種應對快速變化的需求的一種軟件開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於“非敏捷”，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認爲比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發過程中人的作用。
CI：持續集成（CONTINUOUS INTEGRATION）
基本概念
CI的全稱是Continuous Integration，表示持續集成。
在CI環境中，開發人員將會頻繁地向主幹提交代碼。這些新提交的代碼在最終合併到主幹前，需要經過編譯和自動化測試流進行驗證。
持續集成過程中很重視自動化測試驗證結果，以保障所有的提交在合併主線之後的質量問題，對可能出現的一些問題進行預警。
需要具備的條件
團隊需要爲每個新功能、代碼改進、或者問題修復創建自動化測試用例。
你需要一個持續集成服務器，它可以監控代碼提交情況，對每個新的提交進行自動化測試。
研發團隊需要儘可能快的提交代碼，至少每天一次提交。
帶來的效益
通過自動化測試可以提早拿到迴歸測試的結果，避免將一些問題提交到交付生產中。
發佈編譯將會更加容易，因爲合併之初已經將所有問題都規避了。
減少工作問題切換，研發可以很快獲得構建失敗的消息，在開始下一個任務之前就可以很快解決。
測試成本大幅降低，你的CI服務器可以在幾秒鐘之內運行上百條測試。
你的QA團隊花費在測試上面的時間會大幅縮短，將會更加側重於質量文化的提升上面。
CD：持續部署（CONTINUOUS DEPLOYMENT）
基本概念
CD的全稱是Continuous Deployment，表示持續部署。
在CD環境中，通過自動化的構建、測試和部署循環來快速交付高質量的產品。某種程度上代表了一個開發團隊工程化的程度，任何修改通過了所有已有的工作流就會直接和客戶見面，只有當一個修改在工作流中構建失敗才能阻止它部署到產品線。
持續部署是一個很優秀的方式，可以加速與客戶的反饋循環，但是會給團隊帶來壓力，因爲不再有“發佈日”了。開發人員可以專注於構建軟件，他們看到他們的修改在他們完成工作後幾分鐘就上線了。
css 基本上，當開發人員在主分支中合併一個提交時，這個分支將被構建、測試，如果一切順利，則部署到生產環境中。
需要具備的條件
研發團隊測試理念比較完善。測試單元的健壯性直接決定你的交付質量。
你的文檔和部署頻率要保持一致。
特徵標誌成爲發佈重大變化過程的固有部分，以確保您可以與其他部門（支持，市場營銷，公關…）協調。
帶來的效益
發佈頻率更快，因爲你不需要停下來等待發布。每一處提交都會自動觸發發佈流。
在小批量發佈的時候，風險降低了，發現問題也可以很輕鬆的修復。
客戶每天都可以看到我們的持續改進和提升，而不是每個月或者每季度，或者每年。
CD：持續交付（CONTINUOUS DELIVERY）
基本概念
持續交付的英文全稱是：Continuous delivery，縮寫也是CD，它是一種軟件工程手法。
它可以讓軟件產品的產出過程在一個短週期內完成，以保證軟件可以穩定、持續的保持在隨時可以釋出的狀況。它的目標在於讓軟件的建置、測試與釋出變得更快以及更頻繁。這種方式可以減少軟件開發的成本與時間，減少風險。
有時候，持續交付也與持續部署混淆。持續部署意味着所有的變更都會被自動部署到生產環境中。持續交付意味着所有的變更都可以被部署到生產環境中，但是出於業務考慮，可以選擇不部署。如果要實施持續部署，必須先實施持續交付。
需要具備的條件
你需要有強大的持續集成組件和足夠多的測試項可以滿足你代碼的需求。
部署需要自動化。觸發是手動的，但是部署一旦開始，就不能人爲干預。
你的團隊可能需要接受特性開關，沒有完成的功能模塊不會影響到線上產品。
帶來的效益
繁瑣的部署工作沒有了。你的團隊不在需要花費幾天的時間去準備一個發佈。
你可以更快的進行交付，這樣就加快了與客戶之間的反饋環。
輕鬆應對小變更，加速迭代。
————————————————
原文鏈接：https://blog.csdn.net/sinat_35930259/article/details/79429743