敏捷開發(fā)和DevOps開發(fā)運維有哪些相連之處？

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

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

一、敏捷開發(fā)

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

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

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

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

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

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

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

二、SCRUM 工作流程

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

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

Sprint

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

User Story

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

Task

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

Backlog

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

Daily meeting

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

Sprint Review meeting

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

Sprint burn down

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

Release

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

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

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

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

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

三、Devops

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

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

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

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

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

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

1）減少變更范圍

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

2）加強發(fā)布協調

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

3）自動化

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

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

五、實現DevOps需要什么？

硬性要求：工具上的準備

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

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

　　構建工具：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

　　服務注冊與發(fā)現：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

　　應用服務器：Tomcat、JBoss

　　Web服務器：Apache、Nginx、IIS

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

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

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

軟性需求：文化和人

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

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

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

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

審核編輯：鄢孟繁