一酥馍、敏捷開發(fā)
敏捷開發(fā)（Agile）是一種以人為核心、迭代板熊、循序漸進(jìn)的開發(fā)方法框全。
在敏捷開發(fā)中，軟件項(xiàng)目的構(gòu)建被切分成多個(gè)子項(xiàng)目干签，各個(gè)子項(xiàng)目的成果都經(jīng)過測試津辩，具備集成和可運(yùn)行的特征。
簡單地來說筒严，敏捷開發(fā)并不追求前期完美的設(shè)計(jì)丹泉、完美編碼，而是力求在很短的周期內(nèi)開發(fā)出產(chǎn)品的核心功能鸭蛙，盡早發(fā)布出可用的版本摹恨。然后在后續(xù)的生產(chǎn)周期內(nèi)，按照新需求不斷迭代升級(jí)娶视，完善產(chǎn)品晒哄。
敏捷開發(fā)思想是 Martin Fowler 提出的睁宰。 Martin Fowler 不但是敏捷開發(fā)的創(chuàng)始人之一，還在面向?qū)ο箝_發(fā)寝凌、設(shè)計(jì)模式柒傻、UML 建模領(lǐng)域做出了重要貢獻(xiàn)。目前擔(dān)任 ThoughtWorks 公司的首席科學(xué)家较木。
敏捷開發(fā)模式的分類
敏捷開發(fā)的實(shí)現(xiàn)主要包括 SCRUM红符、XP（極限編程）、Crystal Methods伐债、FDD（特性驅(qū)動(dòng)開發(fā)）等等预侯。其中 SCRUM 與 XP 最為流行。
同樣是敏捷開發(fā)峰锁，XP 極限編程更側(cè)重于實(shí)踐萎馅，并力求把實(shí)踐做到極限。這一實(shí)踐可以是測試先行虹蒋，也可以是結(jié)對(duì)編程等糜芳，關(guān)鍵要看具體的應(yīng)用場景。
二魄衅、SCRUM 工作流程
SCRUM則是一種開發(fā)流程框架峭竣，也可以說是一種套路。SCRUM 框架中包含三個(gè)角色晃虫，三個(gè)工件邪驮，四個(gè)會(huì)議，聽起來很復(fù)雜傲茄，其目的是為了有效地完成每一次迭代周期的工作。
學(xué)習(xí) Scrum 之前沮榜，我們先要了解幾個(gè)基本術(shù)語：
Sprint
沖刺周期盘榨，通俗的講就是實(shí)現(xiàn)一個(gè)“小目標(biāo)”的周期。一般需要 2-6 周時(shí)間蟆融。
User Story
用戶的外在業(yè)務(wù)需求草巡。拿銀行系統(tǒng)來舉例的話，一個(gè) Story 可以是用戶的存款行為型酥，或者是查詢余額等等山憨。也就是所謂的小目標(biāo)本身。
Task
由 User Story 拆分成的具體開發(fā)任務(wù)弥喉。
Backlog
需求列表郁竟，可以看成是小目標(biāo)的清單。分為 Sprint Backlog 和 Product Backlog由境。
Daily meeting
每天的站會(huì)棚亩，用于監(jiān)控項(xiàng)目進(jìn)度蓖议。有些公司直接稱其為 Scrum。
Sprint Review meeting
沖刺評(píng)審會(huì)議讥蟆，讓團(tuán)隊(duì)成員們演示成果勒虾。
Sprint burn down
沖刺燃盡圖，說白了就是記錄當(dāng)前周期的需求完成情況瘸彤。
Release
開發(fā)周期完成修然，項(xiàng)目發(fā)布新的可用版本。
如上圖所示质况，在項(xiàng)目啟動(dòng)之前愕宋，會(huì)由團(tuán)隊(duì)的產(chǎn)品負(fù)責(zé)人（Product owner）按照需求優(yōu)先級(jí)來明確出一份 Product Backlog，為項(xiàng)目做出整體排期拯杠。
隨后在每一個(gè)小的迭代周期里掏婶，團(tuán)隊(duì)會(huì)根據(jù)計(jì)劃（Sprint Plan Meeting）確定本周期的 Sprint Backlog，再細(xì)化成一個(gè)個(gè) Task潭陪，分配給團(tuán)隊(duì)成員雄妥，進(jìn)行具體開發(fā)工作。每一天依溯，團(tuán)隊(duì)成員都會(huì)進(jìn)行 Daily meeting老厌，根據(jù)情況更新自己的 Task 狀態(tài)，整個(gè)團(tuán)隊(duì)更新 Sprint burn down chart黎炉。
當(dāng)這一周期的 Sprint backlog 全部完成枝秤，團(tuán)隊(duì)會(huì)進(jìn)行 Spring review meeting，也就是評(píng)審會(huì)議慷嗜。一切順利的話淀弹，會(huì)發(fā)布出這一版本的 Release，并且進(jìn)行 Sprint 回顧會(huì)議（Sprint Retrospective Meeting）庆械。
三薇溃、Devops
DevOps 是 Development 和 Operations 的合成詞，是一組過程缭乘、方法與系統(tǒng)的統(tǒng)稱沐序，用于促進(jìn)開發(fā)（應(yīng)用程序/軟件工程）、技術(shù)運(yùn)營和質(zhì)量保障（QA）部門之間的溝通堕绩、協(xié)作與整合策幼。 它是一種重視“軟件開發(fā)人員（Dev）”和“IT運(yùn)維技術(shù)人員（Ops）”之間溝通合作的文化、運(yùn)動(dòng)或慣例奴紧。透過自動(dòng)化“軟件交付”和“架構(gòu)變更”的流程特姐，來使得構(gòu)建、測試黍氮、發(fā)布軟件能夠更加地快捷到逊、頻繁和可靠铣口。
其目標(biāo)是要加強(qiáng)開發(fā)人員、測試人員觉壶、運(yùn)維人員之間的溝通協(xié)調(diào)脑题。如何實(shí)現(xiàn)這一目標(biāo)呢？需要我們的項(xiàng)目做到持續(xù)集成铜靶、持續(xù)交付叔遂、持續(xù)部署。
時(shí)下流行的 Jenkins争剿、Bamboo已艰，就是兩款優(yōu)秀的持續(xù)集成工具。而 Docker 容器則為 DevOps 提供了強(qiáng)大而有效的統(tǒng)一環(huán)境蚕苇。
DevOps 的出現(xiàn)是由于軟件行業(yè)日益清晰地認(rèn)識(shí)到：為了按時(shí)交付軟件產(chǎn)品和服務(wù)哩掺，開發(fā)和運(yùn)營工作必須緊密合作。
從定義來看涩笤，其實(shí) DevOps 就是為了讓開發(fā)嚼吞、運(yùn)維和QA可以高效協(xié)作的流程。（可以把DevOps看作開發(fā)蹬碧、技術(shù)運(yùn)營和質(zhì)量保障（QA）三者的交集）舱禽。
DevOps對(duì)應(yīng)用程序發(fā)布的影響
在很多企業(yè)中，應(yīng)用程序發(fā)布是一項(xiàng)涉及多個(gè)團(tuán)隊(duì)恩沽、壓力很大誊稚、風(fēng)險(xiǎn)很高的活動(dòng)。然而在具備DevOps能力的組織中，應(yīng)用程序發(fā)布的風(fēng)險(xiǎn)很低，原因如下：
1）減少變更范圍
與傳統(tǒng)的瀑布模式模型相比撵儿，采用敏捷或迭代式開發(fā)意味著更頻繁的發(fā)布、每次發(fā)布包含的變化更少俏脊。由于部署經(jīng)常進(jìn)行，因此每次部署不會(huì)對(duì)生產(chǎn)系統(tǒng)造成巨大影響肤晓，應(yīng)用程序會(huì)以平滑的速率逐漸生長。
2）加強(qiáng)發(fā)布協(xié)調(diào)
靠強(qiáng)有力的發(fā)布協(xié)調(diào)人來彌合開發(fā)與運(yùn)營之間的技能鴻溝和溝通鴻溝认然；采用電子數(shù)據(jù)表补憾、電話會(huì)議和企業(yè)門戶（wiki、sharepoint）等協(xié)作工具來確保所有相關(guān)人員理解變更的內(nèi)容并全力合作卷员。
3）自動(dòng)化
強(qiáng)大的部署自動(dòng)化手段確保部署任務(wù)的可重復(fù)性盈匾、減少部署出錯(cuò)的可能性。
與傳統(tǒng)開發(fā)方法那種大規(guī)模的毕骡、不頻繁的發(fā)布（通常以“季度”或“年”為單位）相比削饵，敏捷方法大大提升了發(fā)布頻率（通常以“天”或“周”為單位）岩瘦。
實(shí)現(xiàn)DevOps需要什么？
硬性要求：工具上的準(zhǔn)備
上文提到了工具鏈的打通窿撬，那么工具自然就需要做好準(zhǔn)備∑裘粒現(xiàn)將工具類型及對(duì)應(yīng)的不完全列舉整理如下：
代碼管理（SCM）：GitHub、GitLab劈伴、BitBucket密末、SubVersion
構(gòu)建工具：Ant、Gradle跛璧、maven
自動(dòng)部署：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景用、etc、Consul
腳本語言：python惭蹂、ruby伞插、shell
日志管理：ELK、Logentries
系統(tǒng)監(jiān)控：Datadog盾碗、Graphite媚污、Icinga、Nagios
性能監(jiān)控：AppDynamics廷雅、New Relic耗美、Splunk
壓力測試：JMeter、Blaze Meter航缀、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ù)庫
項(xiàng)目管理（PM）：Jira、Asana唬格、Taiga家破、Trello、Basecamp购岗、Pivotal Tracker
在工具的選擇上汰聋，需要結(jié)合公司業(yè)務(wù)需求和技術(shù)團(tuán)隊(duì)情況而定。
軟性需求：文化和人
DevOps成功與否喊积，公司組織是否利于協(xié)作是關(guān)鍵烹困。開發(fā)人員和運(yùn)維人員可以良好溝通互相學(xué)習(xí)，從而擁有高生產(chǎn)力乾吻。并且協(xié)作也存在于業(yè)務(wù)人員與開發(fā)人員之間髓梅。
出席了2016年倫敦企業(yè)級(jí)DevOps峰會(huì)的ITV公司在2012年就開始落地DevOps，其通用平臺(tái)主管Clark在接受了InfoQ的采訪绎签，在談及成功時(shí)表示枯饿，業(yè)務(wù)人員非常清楚他們希望在最小化可行產(chǎn)品中實(shí)現(xiàn)什么，工程師們就按需交付诡必，不做多余工作奢方。
這樣，工程師們使用通用的平臺(tái)（即打通的工具鏈）得到更好的一致性和更高的質(zhì)量爸舒。此外蟋字，DevOps對(duì)工程師個(gè)人的要求也提高了，很多專家也認(rèn)為招募到優(yōu)秀的人才也是一個(gè)挑戰(zhàn)扭勉。
