概述
靈活開發和DevOps都是一種理念。他們的理念相似，都是為了更好更快的釋出産品，但又不完全相同。
而CI/CD是實作這兩者理念的一種方法。
靈活開發
前言
傳統方式開發前有一份詳細的開發文檔，程式員照着需求直接敲代碼，産品做好了直接部署上線。中間不會有人打擾，需求也不會變。
但是目前的情況是，使用者需求和市場都變化太快，就算你前期使用者調研的再好，計劃書寫的再詳細，也抵不住市場的變化，說不定産品做出來，使用者就不需要了。
是以為了适應市場的發展，我們必須不斷提高我們的開發效率，及時跟進使用者需求，縮短開發周期。在這種情況下，就有人提出了靈活開發。
傳統開發
傳統開發方式的擁護者和靈活開發方式的擁護者看待軟體開發的世界觀是不同的。
在傳統開發的眼裡，軟體開發過程是确定的、可測的，隻要在一開始努力收集到需要的資訊并制定好計劃，然後忠實的執行計劃就應該可以成功。如果不成功一定是你在一開始就沒有做好，沒收集到必要的資訊，計劃做的不好或者執行不到位。然後傳統開發方式就試圖引入更多的流程，文檔，試圖讓每一步都做到萬無一失。
靈活開發
而在靈活的眼裡世界可不是這樣的，靈活認為在軟體開發中，世界是變化的，有很多不确定首先不論哪種開發方式，不過不管什麼開發方式前期還是要做足充分的調研和分析，收集足夠多的資訊。但是我們不是先知，沒人能確定自己的預測足夠準确，也沒人能保證能收集到所有有用的資訊。但是可以肯定的是随着開發的進行，我們對會對正在做的東西的認識越來越深刻。因而做一段時間後常常有發現需求有調整，或發現之前的想法不對。另一方面，世界本來就是在快速變化中，尤其是網際網路，是以我們也不得不适應這個環境。是以為了适應這個市場的變化，我們要采用靈活開發。
總結
在傳統開發中要做好一個産品，大部分精力都要花在前期
更多調研
更多資訊
更多文檔
缺點
始終走在市場後面，無法緊跟潮流，做出的産品容易被淘汰。
靈活開發核心
擁抱變化
快速疊代
下面圖的标題是How Spotify builds a product.很好的诠釋了靈活開發的含義
CI/CD
概述
可以把開發工作流程分為以下幾個階段：
編碼 -> 建構 -> 內建 -> 測試 -> 傳遞 -> 部署
正如你在上圖中看到，「持續內建（Continuous Integration）」、「持續傳遞（Continuous Delivery）」和「持續部署（Continuous Deployment）」有着不同的軟體自動化傳遞周期。
持續內建CI（Continuous Integration）
基本概念
持續內建（Continuous Integration）簡稱CI，持續內建強調開發人員送出了新代碼之後，立刻自動的進行建構、（單元）測試。根據測試結果，我們可以确定新代碼和原有代碼能否正确地內建在一起。
持續內建過程中很重視自動化測試驗證結果，對可能出現的一些問題進行預警，以保障最終合并的代碼沒有問題。
持續傳遞CD（Continuous Delivery）
基本概念
持續傳遞在持續內建的基礎上，将內建後的代碼部署到更貼近真實運作環境的「類生産環境」（production-like environments）中。傳遞給品質團隊或者使用者，以供評審。如果評審通過，代碼就進入生産階段。
持續傳遞并不是指軟體每一個改動都要盡快部署到産品環境中，它指的是任何的代碼修改都可以在任何時候實施部署。
這裡強調的是
手動部署
有部署的能力，但不一定部署
持續部署（Continuous Deployment）
基本概念
持續部署是指當傳遞的代碼通過評審之後，自動部署到生産環境中。持續部署是持續傳遞的最高階段。
這裡強調
持續部署是自動的
持續部署是持續傳遞的最高階段
持續傳遞（Continuous delivery）與持續部署的關系
有時候，持續傳遞也與持續部署混淆。持續部署意味着所有的變更都會被自動部署到生産環境中。持續傳遞意味着所有的變更都可以被部署到生産環境中，但是出于業務考慮，可以選擇不部署。如果要實施持續部署，必須先實施持續傳遞。
持續傳遞表示的是一種能力
而持續部署則是一種方式
具體實作
整體而言，Jenkins 過去一直是大部分公司的選擇，但這個現象正在發生改變，随着公有雲服務、Docker，SaaS 的普及，越來越多的企業開始選擇線上托管型持續內建系統。
總結
「持續內建（Continuous Integration）」、「持續傳遞（Continuous Delivery）」和「持續部署（Continuous Deployment）」提供了一個優秀的 DevOps 環境，對于整個團隊來說，好處與挑戰并行。無論如何，頻繁部署、快速傳遞以及開發測試流程自動化都将成為未來軟體工程的重要組成部分。
DevOps（開發與運維 – Development and Operations）
産生背景
DevOps是Development和Operations縮寫，現在市場需求和技術變化都非常快，為了配合市場的需求，開發周期就要變短（但是軟體品質不能因為這個原因降低），比如說某些APP可能每周就要更新一次，是以說為了跟上市場的變化，勢必就要縮短開發周期，但是傳統的開發過程中與運維相關的部分比如測試，釋出，部署都很花時間，是以往往開發人員和運維人員之間有着很深的隔閡，并且兩者溝通效率低，為了解決這個問題，使之能夠更專注于開發。就有人提出了DevOps這理念。
DevOps簡單的說就是為了打破傳統開發和運維之間的隔閡與低效，在保證産品品質的前提下實作更自動化、更高效的協作與産品的傳遞。
DevOps是什麼
DevOps（Development和Operations的組合詞）是一種重視“軟體開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。通過自動化“軟體傳遞”和“架構變更”的流程，來使得建構、測試、釋出軟體能夠更加地快捷、頻繁和可靠。
具體來說，就是在軟體傳遞和部署過程中的提高溝通與協作的效率，旨在更快、更可靠的的釋出更高品質的産品。
我們可以列舉下DevOps是幹啥的。
DevOps是一組過程、方法與系統的統稱。用于促進開發、運維和品質保障部門之間的溝通、協作與整合。
DevOps是一種文化轉變，打破了以往開發和運維之間的隔閡，或者說是一個鼓勵更好地交流和協作（即團隊合作）以便于更快地建構可靠性更高、品質更好的軟體的運動。
DevOps 是一種工程模式，本質上是一種分工，通過對開發、運維、測試，配管等角色職責的分工，實作工程效率最大化，進而滿足業務的需求。
DevOps是一種能力，具備此能力的團隊可以高品質、快速的傳遞軟體産品或服務。
DevOps與傳統開發方式差別
傳統的開發方式是線性的，開發與運維之間存在隔閡而且溝通效率低下。而DevOps使開發與運維的流程形成了一個閉環，打破了隔閡，各部門協作更緊密，提高了協作效率。
DevOps好處
依托自動化工具把開發、測試、釋出、部署的過程整合，實作高度自動化與高效傳遞。
在保證産品品質的前提下快速、頻繁地釋出産品。
能夠即使獲得使用者回報，并快速響應。
最大限度地減少風險，降低代碼的出錯率。
高品質的軟體釋出标準。整個傳遞過程标準化、可重複、可靠。
整個傳遞過程進度可視化，友善團隊人員了解并控制項目進度。
團隊協作更高效。
為什麼DevOps姗姗來遲
容器技術開始成熟，特别是docker技術的大行其道。
微服務架構技術的廣泛使用。
微服務是支撐DevOps方法的手段，傳統開發是在一個伺服器裡面，把各種元素裝在一起組合成一個程式，但微服務是每一個服務是一個單獨的單元，可以部署在不同的伺服器上，通過SOA的方法，把它連接配接起來，再提供整個功能。
微服務是由一個個團隊組成，每團隊有自己的服務，做好後，可以獨立的進行測試、開發、部署，然後整個應用組合到一起。
靈活開發流程的深入人心。
諸如Scrum, Agile, Kanban等靈活方式被團隊廣泛使用，TDD、BDD、DDD這些測試驅動設計、行為驅動設計、域驅動設計等設計方式的采納，CI和CD這些持續內建和持續部署等方式的實施，這些都是對DevOps的強烈需求。
DevOps帶來的變革
角色分工：打破傳統團隊隔閡，讓開發、運維緊密結合，高效協作
研發：專注研發、高度靈活、持續內建
産品傳遞：高品質、快速、頻繁、自動化、持續傳遞
具體落地
簡單的說，DevOps=團隊文化+流程+工具
團隊文化的意思很簡單就是你的團隊要知道并認可DevOps理念
然後就要通過具體的流程和工具來實作這個理念。
DevOps工具
簡單列舉下常見的DevOps工具
原文：https://blog.csdn.net/CrankZ/article/details/81545439