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

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

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

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

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

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

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

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

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

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

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

(描繪了軟件模式變化的漫畫 來源：Toggle)

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

　　有觀點認為，瀑布式的主要的問題是它的嚴格分級導致的自由度降低，項目早期即作出承諾導致對后期需求的變化難以調(diào)整，代價高昂。

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

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

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

　　既是對傳統(tǒng)的反叛，也是對野蠻生長的規(guī)范，敏捷運動應運而生。

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

詳情請見： http://agilemanifesto.org/

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

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

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

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

圖片來源：https://blog.csdn.net/xiajun2356033/article/details/81513957

　　DevOps帶來的改變是巨大的

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

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

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

圖片來源于：https://www.cnblogs.com/liufei1983/p/7152013.html

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

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

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

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

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

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

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

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

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