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

下面由深圳青藍(lán)咨詢的小編給大家來講解！

一、敏捷開發(fā)

敏捷開發(fā)（Agile）是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法。

在敏捷開發(fā)中，軟件項目的構(gòu)建被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備集成和可運(yùn)行的特征。

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

敏捷開發(fā)思想是 Martin Fowler 提出的。 Martin Fowler 不但是敏捷開發(fā)的創(chuàng)始人之一，還在面向?qū)ο箝_發(fā)、設(shè)計模式、UML 建模領(lǐng)域做出了重要貢獻(xiàn)。目前擔(dān)任 ThoughtWorks 公司的首席科學(xué)家。

敏捷開發(fā)模式的分類

敏捷開發(fā)的實(shí)現(xiàn)主要包括 SCRUM、XP（極限編程）、Crystal Methods、FDD（特性驅(qū)動開發(fā)）等等。其中 SCRUM 與 XP 最為流行。

同樣是敏捷開發(fā)，XP 極限編程更側(cè)重于實(shí)踐，并力求把實(shí)踐做到極限。這一實(shí)踐可以是測試先行，也可以是結(jié)對編程等，關(guān)鍵要看具體的應(yīng)用場景。

二、SCRUM 工作流程

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

學(xué)習(xí) Scrum 之前，我們先要了解幾個基本術(shù)語：

Sprint

沖刺周期，通俗的講就是實(shí)現(xiàn)一個“小目標(biāo)”的周期。一般需要 2-6 周時間。

User Story

用戶的外在業(yè)務(wù)需求。拿銀行系統(tǒng)來舉例的話，一個 Story 可以是用戶的存款行為，或者是查詢余額等等。也就是所謂的小目標(biāo)本身。

Task

由 User Story 拆分成的具體開發(fā)任務(wù)。

Backlog

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

Daily meeting

每天的站會，用于監(jiān)控項目進(jìn)度。有些公司直接稱其為 Scrum。

Sprint Review meeting

沖刺評審會議，讓團(tuán)隊成員們演示成果。

Sprint burn down

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

Release

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

如上圖所示，在項目啟動之前，會由團(tuán)隊的產(chǎn)品負(fù)責(zé)人（Product owner）按照需求優(yōu)先級來明確出一份 Product Backlog，為項目做出整體排期。

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

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

那么，現(xiàn)實(shí)中的 Scrum 是什么樣的情景呢？看看下面的照片就知道了：

三、Devops

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

時下流行的 Jenkins、Bamboo，就是兩款優(yōu)秀的持續(xù)集成工具。而 Docker 容器則為 DevOps 提供了強(qiáng)大而有效的統(tǒng)一環(huán)境。

DevOps 的出現(xiàn)是由于軟件行業(yè)日益清晰地認(rèn)識到：為了按時交付軟件產(chǎn)品和服務(wù)，開發(fā)和運(yùn)營工作必須緊密合作。

從定義來看，其實(shí) DevOps 就是為了讓開發(fā)、運(yùn)維和QA可以高效協(xié)作的流程。（可以把DevOps看作開發(fā)、技術(shù)運(yùn)營和質(zhì)量保障（QA）三者的交集）。

四、DevOps對應(yīng)用程序發(fā)布的影響

在很多企業(yè)中，應(yīng)用程序發(fā)布是一項涉及多個團(tuán)隊、壓力很大、風(fēng)險很高的活動。然而在具備DevOps能力的組織中，應(yīng)用程序發(fā)布的風(fēng)險很低，原因如下：

1）減少變更范圍

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

2）加強(qiáng)發(fā)布協(xié)調(diào)

靠強(qiáng)有力的發(fā)布協(xié)調(diào)人來彌合開發(fā)與運(yùn)營之間的技能鴻溝和溝通鴻溝；采用電子數(shù)據(jù)表、電話會議和企業(yè)門戶（wiki、sharepoint）等協(xié)作工具來確保所有相關(guān)人員理解變更的內(nèi)容并全力合作。

3）自動化

強(qiáng)大的部署自動化手段確保部署任務(wù)的可重復(fù)性、減少部署出錯的可能性。

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

五、實(shí)現(xiàn)DevOps需要什么？

硬性要求：工具上的準(zhǔn)備

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

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

　　構(gòu)建工具：Ant、Gradle、maven

　　自動部署：Capistrano、CodeDeploy

　　持續(xù)集成（CI）：Bamboo、Hudson、Jenkins

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

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

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

　　服務(wù)注冊與發(fā)現(xiàn)：Zookeeper、etcd、Consul

　　腳本語言：python、ruby、shell

　　日志管理：ELK、Logentries

　　系統(tǒng)監(jiān)控：Datadog、Graphite、Icinga、Nagios

　　性能監(jiān)控：AppDynamics、New Relic、Splunk

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

　　預(yù)警：PagerDuty、pingdom、廠商自帶如AWS SNS

　　HTTP加速器：Varnish

　　消息總線：ActiveMQ、SQS

　　應(yīng)用服務(wù)器：Tomcat、JBoss

　　Web服務(wù)器：Apache、Nginx、IIS

　　數(shù)據(jù)庫：MySQL、Oracle、PostgreSQL等關(guān)系型數(shù)據(jù)庫；cassandra、mongoDB、redis等NoSQL數(shù)據(jù)庫

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

在工具的選擇上，需要結(jié)合公司業(yè)務(wù)需求和技術(shù)團(tuán)隊情況而定。

軟性需求：文化和人

DevOps成功與否，公司組織是否利于協(xié)作是關(guān)鍵。開發(fā)人員和運(yùn)維人員可以良好溝通互相學(xué)習(xí)，從而擁有高生產(chǎn)力。并且協(xié)作也存在于業(yè)務(wù)人員與開發(fā)人員之間。

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

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

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

審核編輯：鄢孟繁