敏捷開發和DevOps開發運維有哪些相連之處？這個問題一直困擾著很多人！

下面由深圳青藍咨詢的小編給大家來講解！

一、敏捷開發

敏捷開發（Agile）是一種以人為核心、迭代、循序漸進的開發方法。

在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。

簡單地來說，敏捷開發并不追求前期完美的設計、完美編碼，而是力求在很短的周期內開發出產品的核心功能，盡早發布出可用的版本。然后在后續的生產周期內，按照新需求不斷迭代升級，完善產品。

敏捷開發思想是 Martin Fowler 提出的。 Martin Fowler 不但是敏捷開發的創始人之一，還在面向對象開發、設計模式、UML 建模領域做出了重要貢獻。目前擔任 ThoughtWorks 公司的首席科學家。

敏捷開發模式的分類

敏捷開發的實現主要包括 SCRUM、XP（極限編程）、Crystal Methods、FDD（特性驅動開發）等等。其中 SCRUM 與 XP 最為流行。

同樣是敏捷開發，XP 極限編程更側重于實踐，并力求把實踐做到極限。這一實踐可以是測試先行，也可以是結對編程等，關鍵要看具體的應用場景。

二、SCRUM 工作流程

SCRUM則是一種開發流程框架，也可以說是一種套路。SCRUM 框架中包含三個角色，三個工件，四個會議，聽起來很復雜，其目的是為了有效地完成每一次迭代周期的工作。

學習 Scrum 之前，我們先要了解幾個基本術語：

Sprint

沖刺周期，通俗的講就是實現一個“小目標”的周期。一般需要 2-6 周時間。

User Story

用戶的外在業務需求。拿銀行系統來舉例的話，一個 Story 可以是用戶的存款行為，或者是查詢余額等等。也就是所謂的小目標本身。

Task

由 User Story 拆分成的具體開發任務。

Backlog

需求列表，可以看成是小目標的清單。分為 Sprint Backlog 和 Product Backlog。

Daily meeting

每天的站會，用于監控項目進度。有些公司直接稱其為 Scrum。

Sprint Review meeting

沖刺評審會議，讓團隊成員們演示成果。

Sprint burn down

沖刺燃盡圖，說白了就是記錄當前周期的需求完成情況。

Release

開發周期完成，項目發布新的可用版本。

如上圖所示，在項目啟動之前，會由團隊的產品負責人（Product owner）按照需求優先級來明確出一份 Product Backlog，為項目做出整體排期。

隨后在每一個小的迭代周期里，團隊會根據計劃（Sprint Plan Meeting）確定本周期的 Sprint Backlog，再細化成一個個 Task，分配給團隊成員，進行具體開發工作。每一天，團隊成員都會進行 Daily meeting，根據情況更新自己的 Task 狀態，整個團隊更新 Sprint burn down chart。

當這一周期的 Sprint backlog 全部完成，團隊會進行 Spring review meeting，也就是評審會議。一切順利的話，會發布出這一版本的 Release，并且進行 Sprint 回顧會議（Sprint Retrospective Meeting）。

那么，現實中的 Scrum 是什么樣的情景呢？看看下面的照片就知道了：

三、Devops

DevOps是Development and Operations的復合詞，是一組流程、方法和系統的統稱，用于促進開發(應用/軟件工程)、技術運營和質量保證(QA)部門之間的溝通、協作和集成。IT是重視“軟件開發人員(DEVs)”與“IT運維技術人員(Ops)”之間的溝通與合作的文化、運動或習俗。通過自動化“軟件交付”和“架構變更”的過程，軟件可以更快、更頻繁、更可靠地構建、測試和發布。其目標是加強開發人員、測試人員和運維人員之間的溝通和協調。如何達到這個目的？我們的項目需要持續集成、持續交付和持續部署。

時下流行的 Jenkins、Bamboo，就是兩款優秀的持續集成工具。而 Docker 容器則為 DevOps 提供了強大而有效的統一環境。

DevOps 的出現是由于軟件行業日益清晰地認識到：為了按時交付軟件產品和服務，開發和運營工作必須緊密合作。

從定義來看，其實 DevOps 就是為了讓開發、運維和QA可以高效協作的流程。（可以把DevOps看作開發、技術運營和質量保障（QA）三者的交集）。

四、DevOps對應用程序發布的影響

在很多企業中，應用程序發布是一項涉及多個團隊、壓力很大、風險很高的活動。然而在具備DevOps能力的組織中，應用程序發布的風險很低，原因如下：

1）減少變更范圍

與傳統的瀑布模式模型相比，采用敏捷或迭代式開發意味著更頻繁的發布、每次發布包含的變化更少。由于部署經常進行，因此每次部署不會對生產系統造成巨大影響，應用程序會以平滑的速率逐漸生長。

2）加強發布協調

靠強有力的發布協調人來彌合開發與運營之間的技能鴻溝和溝通鴻溝；采用電子數據表、電話會議和企業門戶（wiki、sharepoint）等協作工具來確保所有相關人員理解變更的內容并全力合作。

3）自動化

強大的部署自動化手段確保部署任務的可重復性、減少部署出錯的可能性。

與傳統開發方法那種大規模的、不頻繁的發布（通常以“季度”或“年”為單位）相比，敏捷方法大大提升了發布頻率（通常以“天”或“周”為單位）。

五、實現DevOps需要什么？

硬性要求：工具上的準備

上文提到了工具鏈的打通，那么工具自然就需要做好準備。現將工具類型及對應的不完全列舉整理如下：

　　代碼管理（SCM）：GitHub、GitLab、BitBucket、SubVersion

　　構建工具：Ant、Gradle、maven

　　自動部署：Capistrano、CodeDeploy

　　持續集成（CI）：Bamboo、Hudson、Jenkins

　　配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail

　　容器：Docker、LXC、第三方廠商如AWS

　　編排：Kubernetes、Core、Apache Mesos、DC/OS

　　服務注冊與發現：Zookeeper、etcd、Consul

　　腳本語言：python、ruby、shell

　　日志管理：ELK、Logentries

　　系統監控：Datadog、Graphite、Icinga、Nagios

　　性能監控：AppDynamics、New Relic、Splunk

　　壓力測試：JMeter、Blaze Meter、http://loader.io

　　預警：PagerDuty、pingdom、廠商自帶如AWS SNS

　　HTTP加速器：Varnish

　　消息總線：ActiveMQ、SQS

　　應用服務器：Tomcat、JBoss

　　Web服務器：Apache、Nginx、IIS

　　數據庫：MySQL、Oracle、PostgreSQL等關系型數據庫；cassandra、mongoDB、redis等NoSQL數據庫

　　項目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker

在工具的選擇上，需要結合公司業務需求和技術團隊情況而定。

軟性需求：文化和人

DevOps成功與否，公司組織是否利于協作是關鍵。開發人員和運維人員可以良好溝通互相學習，從而擁有高生產力。并且協作也存在于業務人員與開發人員之間。

出席了2016年倫敦企業級DevOps峰會的ITV公司在2012年就開始落地DevOps，其通用平臺主管Clark在接受了InfoQ的采訪，在談及成功時表示，業務人員非常清楚他們希望在最小化可行產品中實現什么，工程師們就按需交付，不做多余工作。

這樣，工程師們使用通用的平臺（即打通的工具鏈）得到更好的一致性和更高的質量。此外，DevOps對工程師個人的要求也提高了，很多專家也認為招募到優秀的人才也是一個挑戰。

參考文章：http://www.shzhchina.com/newsview.aspx?id=354
?

審核編輯：鄢孟繁