上個(gè)世紀(jì)四五十年代，程序設(shè)計(jì)剛剛誕生之際，是沒(méi)有“軟件”的概念的。硬件是開(kāi)發(fā)的主體，規(guī)模小、工具簡(jiǎn)單，而且主要是用于科學(xué)計(jì)算。

　　隨著軟件概念興起，一些針對(duì)軟件開(kāi)發(fā)的“小作坊”也隨之涌現(xiàn)。作坊做法往往隨意，以個(gè)別編程員的意愿為主，沒(méi)有形成明確標(biāo)準(zhǔn)，效率不高。此外，“作坊”式開(kāi)發(fā)特別倚重個(gè)人能力，大多都雜亂無(wú)章，軟件質(zhì)量也無(wú)從保障。

　　20 世紀(jì) 70 年代開(kāi)始，“工程化”思維開(kāi)始進(jìn)入軟件開(kāi)發(fā)流程。主要原因是，信息技術(shù)發(fā)展迅速，人們對(duì)軟件的需求變大，軟件生產(chǎn)必須提高產(chǎn)能，走向規(guī)?；?。

　　然而，從工業(yè)借鑒而來(lái)的開(kāi)發(fā)流程是否真的適合軟件開(kāi)發(fā)呢?隨著社會(huì)不斷發(fā)展，數(shù)字技術(shù)打破了各行各業(yè)的生產(chǎn)范式，軟件開(kāi)發(fā)自身也并沒(méi)有停止進(jìn)化。這些年，軟件開(kāi)發(fā)流程都經(jīng)歷了些什么呢?

　　師從工業(yè)的瀑布式開(kāi)發(fā)

　　1913年，福特開(kāi)發(fā)出了世界上第一條流水線，打破了汽車(chē)制造業(yè)的手工作坊式生產(chǎn)方式，這一模式的出現(xiàn)改變了世界。標(biāo)準(zhǔn)化和規(guī)模生產(chǎn)將汽車(chē)帶入了尋常百姓家。

　　在軟件開(kāi)發(fā)陷入生產(chǎn)效能無(wú)法滿足日漸擴(kuò)大的需求的困境中時(shí)，福特的“流水線”概念或許多多少少啟發(fā)到了當(dāng)時(shí)的軟件開(kāi)發(fā)者們。

　　瀑布式開(kāi)發(fā)(Waterfall)由此出現(xiàn)。大多數(shù)觀點(diǎn)認(rèn)為，傳統(tǒng)瀑布式開(kāi)發(fā)有不少于30年的歷史。

　　其根源可以追溯到 1970 年，那一年溫斯頓·羅伊斯(Winston Royce)在論文《管理大型軟件系統(tǒng)開(kāi)發(fā)》(Managing the Development of Larger Software Systems)中提出，將軟件生命周期劃分為制定計(jì)劃、需求分析、軟件設(shè)計(jì)、程序編寫(xiě)、軟件測(cè)試和運(yùn)行維護(hù)等六個(gè)基本活動(dòng)，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級(jí)下落。

　　瀑布模型將軟件生存周期的各項(xiàng)活動(dòng)規(guī)定為按固定順序而連接的若干階段工作，形如瀑布流水，直到80年代早期，它一直是唯一被廣泛采用的軟件開(kāi)發(fā)模型。

　　但是，這樣套用傳統(tǒng)工業(yè)生產(chǎn)的方法，多少會(huì)有不適應(yīng)計(jì)算機(jī)軟件開(kāi)發(fā)的弊病。因?yàn)檫^(guò)程是線性的，沒(méi)有充分照顧到客戶需求，難免會(huì)鬧出一些笑話：比如客戶希望你造一輛汽車(chē)，卻經(jīng)費(fèi)不夠，但瀑布式開(kāi)發(fā)要在汽車(chē)完成生產(chǎn)和測(cè)試之后，一次性交付到客戶手中，需求溝通不足導(dǎo)致最后交付的卻是一輛自行車(chē)。

(描繪了軟件模式變化的漫畫(huà) 來(lái)源：Toggle)

　　瀑布式開(kāi)發(fā)模式較好的例子是微軟。微軟 Office 、 Windows 等主打產(chǎn)品的更新周期一般 3 年左右，軟件延期發(fā)布也是家常便飯，因此其軟件產(chǎn)品遭受大家詬病也是無(wú)可厚非。隨后，微軟不得不放棄傳統(tǒng)的瀑布式開(kāi)發(fā)模式，改變產(chǎn)品研發(fā)策略。

　　有觀點(diǎn)認(rèn)為，瀑布式的主要的問(wèn)題是它的嚴(yán)格分級(jí)導(dǎo)致的自由度降低，項(xiàng)目早期即作出承諾導(dǎo)致對(duì)后期需求的變化難以調(diào)整，代價(jià)高昂。

　　因此，在需求不明并且在項(xiàng)目進(jìn)行過(guò)程中可能發(fā)生變化的情況下，瀑布式基本是不可行的。

　　向客戶傾斜的敏捷開(kāi)發(fā)

　　時(shí)間到了上個(gè)世紀(jì)90年代，一批輕量的軟件工程方法和框架相繼誕生，它們共同的特點(diǎn)是，相對(duì)傳統(tǒng)軟件工程，都遵循演進(jìn)和迭代的模型，過(guò)程更加輕量靈活。

　　既是對(duì)傳統(tǒng)的反叛，也是對(duì)野蠻生長(zhǎng)的規(guī)范，敏捷運(yùn)動(dòng)應(yīng)運(yùn)而生。

　　2001 年 2 月，17 位輕量級(jí)軟件工程方法的代表人物，齊聚美國(guó)猶他州的雪鳥(niǎo)滑雪勝地，其中也包括 Scrum 和極限編程的幾位發(fā)明人。在兩天的會(huì)議之后，敏捷宣言發(fā)布。

詳情請(qǐng)見(jiàn)： http://agilemanifesto.org/

　　敏捷概念的出現(xiàn)，可以說(shuō)適逢其時(shí)，立即在當(dāng)時(shí)發(fā)展成為了一場(chǎng)運(yùn)動(dòng)，被迅速地推廣和應(yīng)用。在早期，敏捷專(zhuān)注研發(fā)交付，目標(biāo)是幫助產(chǎn)品和研發(fā)團(tuán)隊(duì)提升敏捷響應(yīng)能力。

　　但是，之后敏捷開(kāi)發(fā)開(kāi)始向客戶靠攏，成為以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開(kāi)發(fā)。在敏捷開(kāi)發(fā)中，客戶會(huì)參與到軟件開(kāi)發(fā)的整個(gè)流程中。整個(gè)開(kāi)發(fā)過(guò)程不再是一堵不透風(fēng)的墻，透明是關(guān)鍵(TRANSPARENCY IS KEY)，但是，隨著越來(lái)越多的用戶參與進(jìn)來(lái)，越來(lái)越多的問(wèn)題也暴露出來(lái)了，越來(lái)越多不著調(diào)的需求也會(huì)被提出。

　　因此，在敏捷開(kāi)發(fā)中，軟件項(xiàng)目在構(gòu)建初期被切分成多個(gè)子項(xiàng)目，各個(gè)子項(xiàng)目的成果都經(jīng)過(guò)測(cè)試，具備可視、可集成和可運(yùn)行使用的特征。換言之，就是把一個(gè)大項(xiàng)目分為多個(gè)相互聯(lián)系，可獨(dú)立運(yùn)行的小項(xiàng)目，在此過(guò)程中軟件一直處于可使用狀態(tài)。

　　在微軟云計(jì)算 Azure 的理解中，敏捷的基礎(chǔ)是創(chuàng)建工作原型或在需求和要求不斷變化的現(xiàn)實(shí)中構(gòu)建。彌合開(kāi)發(fā)團(tuán)隊(duì)和最終用戶之間的差距，適應(yīng)性是敏捷的核心屬性，優(yōu)先考慮用戶和利益干系人的需求，而不是嚴(yán)格的計(jì)劃。

圖片來(lái)源：https://blog.csdn.net/xiajun2356033/article/details/81513957

　　DevOps帶來(lái)的改變是巨大的

　　顯然，敏捷并沒(méi)有將“運(yùn)維”作為關(guān)注的重點(diǎn)。實(shí)際上，光有系統(tǒng)開(kāi)發(fā)是不夠的，開(kāi)發(fā)完的系統(tǒng)必須即時(shí)順利部署，并連續(xù)穩(wěn)定運(yùn)行才能夠?qū)崿F(xiàn)價(jià)值。而傳統(tǒng)上，這部分是由運(yùn)維負(fù)責(zé)的。

　　《阿里巴巴 DevOps 實(shí)踐》認(rèn)為，從價(jià)值的角度，開(kāi)發(fā)加運(yùn)維才構(gòu)成相對(duì)完整的 IT 價(jià)值鏈。而DevOps 的誕生，正是為了解決IT 價(jià)值鏈的最突出問(wèn)題——開(kāi)發(fā)和運(yùn)維之間的問(wèn)題。

　　在傳統(tǒng)的 IT 組織下，開(kāi)發(fā)團(tuán)隊(duì) (Dev) 和運(yùn)維團(tuán)隊(duì) (Ops) 之間有一道無(wú)形的部門(mén)墻。開(kāi)發(fā)團(tuán)隊(duì)(尤其是敏捷團(tuán)隊(duì)) 追求變化，運(yùn)維團(tuán)隊(duì)追求穩(wěn)定，二者存在利益沖突。

圖片來(lái)源于：https://www.cnblogs.com/liufei1983/p/7152013.html

　　2009 年，比利時(shí)獨(dú)立 IT 咨詢師 Patrick Debois 組織了第一屆 DevOpsDays， DevOps 正式登上舞臺(tái)。此后，DevOps 發(fā)展迅速，已經(jīng)為企業(yè)數(shù)字化的核心能力之一，是對(duì) IT 交付和運(yùn)行的基本要求。其中，以容器化和自動(dòng)編排調(diào)度為代表的云原生技術(shù)的出現(xiàn)極大加速了這一進(jìn)程。

　　根據(jù)微軟云計(jì)算 Azure，DevOps 的獨(dú)特之處在于開(kāi)發(fā)、IT 運(yùn)營(yíng)、質(zhì)量工程和安全團(tuán)隊(duì)協(xié)同工作，在發(fā)布新產(chǎn)品、版本或更新所涉及的所有任務(wù)中創(chuàng)造效率。其中，DevOps 的主要表現(xiàn)形式包括持續(xù)集成、持續(xù)交付和連續(xù)部署。

　　在 《鳳凰項(xiàng)目》和《DevOps 實(shí)踐指南》兩本書(shū)中，Gene Kim 等人總結(jié)了 DevOps 實(shí)施的三步工作法：

• 流動(dòng)原則:聚焦 IT 系統(tǒng)的整體價(jià)值流，全局優(yōu)化，保證價(jià)值從左(上游)到右(下游)的快速流動(dòng)。
• 反饋原則:創(chuàng)建從左到右的反饋循環(huán)，并縮短反饋周期和放大反饋效果。這樣，就可以更快的響應(yīng)和理解內(nèi)外部客戶，并即時(shí)獲取改進(jìn)所需要的知識(shí)。
• 持續(xù)的實(shí)驗(yàn)和學(xué)習(xí)原則:創(chuàng)建承擔(dān)風(fēng)險(xiǎn)、持續(xù)實(shí)驗(yàn)并從錯(cuò)誤中學(xué)習(xí)的文化，在不斷的嘗試中精進(jìn)能力，并提高系統(tǒng)的韌性。

　　在現(xiàn)實(shí)操作中，DevOps 也不乏實(shí)現(xiàn)工具。比如我國(guó)國(guó)產(chǎn)的飛算 SoFlu 全自動(dòng)軟件工程平臺(tái)，其出發(fā)點(diǎn)是想讓 DevOps 真正的落地，而實(shí)現(xiàn)“落地”，首先重點(diǎn)要解決的就是開(kāi)發(fā)的問(wèn)題， 包括開(kāi)發(fā)的品質(zhì)、安全和效率等，再逐步解決測(cè)試和運(yùn)維問(wèn)題。

　　除了飛算 SoFlu 全自動(dòng)軟件工程平臺(tái)，幫助 DevOps 實(shí)現(xiàn)組織落地的工具不在少數(shù)，其中還包括開(kāi)源的 CI/CD 服務(wù)器 Jenkins、容器平臺(tái) Docker等等。

　　此外，值得關(guān)注的，在主流觀點(diǎn)中DevOps 成功與否的重點(diǎn)，或許不在現(xiàn)實(shí)層面，而在于文化。Puppet field CTO Nigel Kersten 就曾表示，“仍然存在組織對(duì)變革的抵制，這是一個(gè)真正的問(wèn)題。而且人們真的沒(méi)有看到他們實(shí)際上試圖通過(guò) DevOps 實(shí)現(xiàn)的實(shí)際價(jià)值。”

　　從瀑布式開(kāi)發(fā)、到敏捷，再到目前最流行的DevOps，不難發(fā)現(xiàn)，軟件開(kāi)發(fā)流程正在向自動(dòng)化、便捷化和智能化的方向發(fā)展，而這樣的發(fā)展會(huì)大大加快開(kāi)發(fā)效率、降低開(kāi)發(fā)門(mén)檻，讓未來(lái)的開(kāi)發(fā)流程呈現(xiàn)出全然不同的樣貌。

特別提醒：本網(wǎng)信息來(lái)自于互聯(lián)網(wǎng)，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點(diǎn)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實(shí)，對(duì)本文以及其中全部或者部分內(nèi)容、文字的真實(shí)性、完整性、及時(shí)性本站不作任何保證或承諾，并請(qǐng)自行核實(shí)相關(guān)內(nèi)容。本站不承擔(dān)此類(lèi)作品侵權(quán)行為的直接責(zé)任及連帶責(zé)任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益，請(qǐng)及時(shí)聯(lián)系我們，本站將會(huì)在24小時(shí)內(nèi)處理完畢。