敏捷開發、持續集成/交付（CI/CD）、DevOps

時間 2019-12-18

標籤敏捷開發持續集成交付 devops 简体版

原文原文鏈接

本文連接： http://www.javashuo.com/article/p-tuhsjzck-ga.html

概述

敏捷開發和DevOps都是一種理念。他們的理念類似，都是爲了更好更快的發佈產品，但又不徹底相同。css

而CI/CD是實現這二者理念的一種方法。html

敏捷開發

前言

傳統方式開發前有一份詳細的開發文檔，程序員照着需求直接敲代碼，產品作好了直接部署上線。中間不會有人打擾，需求也不會變。程序員

可是目前的狀況是，用戶需求和市場都變化太快，就算你前期用戶調研的再好，計劃書寫的再詳細，也抵不住市場的變化，說不定產品作出來，用戶就不須要了。docker

因此爲了適應市場的發展，咱們必須不斷提升咱們的開發效率，及時跟進用戶需求，縮短開發週期。在這種狀況下，就有人提出了敏捷開發。segmentfault

傳統開發

傳統開發方式的擁護者和敏捷開發方式的擁護者看待軟件開發的世界觀是不一樣的。
在傳統開發的眼裏，軟件開發過程是肯定的、可測的，只要在一開始努力收集到須要的信息並制定好計劃，而後忠實的執行計劃就應該能夠成功。若是不成功必定是你在一開始就沒有作好，沒收集到必要的信息，計劃作的很差或者執行不到位。而後傳統開發方式就試圖引入更多的流程，文檔，試圖讓每一步都作到萬無一失。服務器

敏捷開發

而在敏捷的眼裏世界可不是這樣的，敏捷認爲在軟件開發中，世界是變化的，有不少不肯定首先不論哪一種開發方式，不過無論什麼開發方式前期仍是要作足充分的調研和分析，收集足夠多的信息。可是咱們不是先知，沒人能確保本身的預測足夠準確，也沒人能保證能收集到全部有用的信息。可是能夠確定的是隨着開發的進行，咱們對會對正在作的東西的認識愈來愈深入。於是作一段時間後經常有發現需求有調整，或發現以前的想法不對。另外一方面，世界原本就是在快速變化中，尤爲是互聯網，因此咱們也不得不適應這個環境。因此爲了適應這個市場的變化，咱們要採用敏捷開發。架構

總結

在傳統開發中要作好一個產品，大部分精力都要花在前期運維

更多調研
更多信息
更多文檔

缺點微服務

始終走在市場後面，沒法緊跟潮流，作出的產品容易被淘汰。工具

敏捷開發核心

擁抱變化
快速迭代

下面圖的標題是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的強烈需求。