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

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

一、敏捷開發(fā)

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

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

簡單地來說，敏捷開發(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)域做出了重要貢獻。目前擔任 ThoughtWorks 公司的首席科學家。

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

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

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

二、SCRUM 工作流程

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

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

Sprint

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

User Story

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

Task

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

Backlog

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

Daily meeting

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

Sprint Review meeting

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

Sprint burn down

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

Release

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

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

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

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

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

三、Devops

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

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

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

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

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

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

1）減少變更范圍

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

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

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

3）自動化

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

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

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

硬性要求：工具上的準備

上文提到了工具鏈的打通，那么工具自然就需要做好準備?，F(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

　　預警：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ù)團隊情況而定。

軟性需求：文化和人

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

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

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

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

審核編輯：鄢孟繁