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

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

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

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

　　師從工業的瀑布式開發

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

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

　　瀑布式開發(Waterfall)由此出現。大多數觀點認為，傳統瀑布式開發有不少于30年的歷史。

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

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

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

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

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

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

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

　　向客戶傾斜的敏捷開發

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

　　既是對傳統的反叛，也是對野蠻生長的規范，敏捷運動應運而生。

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

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

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

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

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

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

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

　　DevOps帶來的改變是巨大的

　　顯然，敏捷并沒有將“運維”作為關注的重點。實際上，光有系統開發是不夠的，開發完的系統必須即時順利部署，并連續穩定運行才能夠實現價值。而傳統上，這部分是由運維負責的。

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

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

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

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

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

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

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

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

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

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

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

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