敏捷開發、持續整合/交付（CI/CD）、DevOps學習筆記
概述
敏捷開發和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://segmentfault.com/a/1190000006166538
http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html
https://acejoy.com/2018/04/20/438/
https://zh.wikipedia.org/wiki/%E6%8C%81%E7%BA%8C%E4%BA%A4%E4%BB%98
https://zh.wikipedia.org/wiki/DevOps