編輯導語：隨著網際網路的發展，使用者對於產品的需求越來越高，更多的使用者追求“好看”和“好用”。本文作者分享了一種新的開發模式——DevOps開發模式的發展和開發模式，感興趣的一起來看看吧。

瀑布開發大家肯定大學都學過吧，敏捷開發大家肯定工作中都聽過吧，現在又搞出來個DevOps開發，這個估計就知道的不多了吧~

來，一起來接受知識的洗禮吧，知識就是力量，就是金錢，奧利給！

先告訴大家兩句話，第一句話是趨勢，第二句話是概念。

趨勢：

目前很多大廠如阿里、騰訊、百度、頭條、美團等公司內部都在用DevOps開發模式。

概念：

DevOps=Developers（開發）+Operators（運維），即開發團隊和運維團隊一體化。

哈，只看概念啥感覺？是不是感覺概念是不可能看懂的，這輩子都不可能看懂的。

沒關係，在這裡只記住兩件事即可：第一件事就是，

DevOps是把開發和運維繫結到一起了

；第二件事就是，

DevOps不是工具什麼的，而是一種方法論

。

其他的交給我，往下看，保證給你講解的明明白白的。

一、發展歷史

想要了解一個新的事物為什麼會出現，就比如DevOps，那麼最好的方法，就是去了解他的過去，他的歷史。

前面說了，DevOps是一種開發模式，提到“開發模式”這四個字，你能想到什麼？是不是瀑布開發和敏捷開發？

好，我們就先來扒拉一下，這兩種開發模式的演進歷史。

二、瀑布開發

1。 背景

在網際網路初期，程式設計師還是科學家一樣的存在，當時程式設計師的辦公室還被稱作實驗室。

當時的網民，也還沒有那麼多，大多數時候，他們都是帶著敬畏之心提需求的。

並且開發出來的產品，只要能解決他們的問題，他們都是爭先恐後地給程式設計師燒高香、送錦旗，對研發週期，自然不敢有太多的要求，需求也自然是不變的。

在這種大背景下，就誕生了瀑布開發的模式，如下圖所示：

2。 特點

瀑布開發模式，最大的特點有三個：

需求是固定的；

開發週期是固定的，可能為3個月，也有可能是1年；

設計、開發、測試、運維各個環節是獨立的，當前一個環節完全搞定，下一個環節才開始介入。

3。 弊端

這種模式的弊端，相信大家都知道，總結一下就是：

需求不能快速得到驗證！

有可能花了1年開發出來的東西，早已時過境遷，不再適合市場；也有可能你搞了半年之後，發現搞出來的東西跟使用者的需求完全驢唇不對馬嘴，只能完全推翻，一切重頭再來。

這個時候啊，敏捷開發出現了。

三、敏捷開發

1。 背景

隨著時代的發展，網際網路的網民越來越多了，而且這些網民的口味也越來越刁了。

搞出來的產品，只是“能用”，已經滿足不了他們的胃口了，更多的網民越來越追求“好用”以及“好看”。

而且這些人也變得越來越“朝三暮四”了，可能今天覺得這個好，明天就覺得那個好了，軟體開發的週期，也被壓縮的越來越短。

時代的大背景下，總有那麼幾個腦子進化的比較快的，於是乎，敏捷開發模式，登上了歷史的舞臺：

2。 特點

最大的特點就是一個字：更快！

具體來說，敏捷開發可以更快地發現問題，產品被更快地交付到使用者手中，團隊可以更快地得到使用者的反饋，從而進行更快地響應。

另外一個特點，

就是將開發與測試從對立關係，變成了同一戰線。

瀑布模式的時候，測試的工作，就是為了儘可能地挑開發搞出來東西的毛病，妥妥的你死我活。而敏捷開發，則將二者目標進行了統一，都為了能夠更快更好地開發出產品而共同努力。

從敏捷宣言中，我們可以窺見其中的真諦：

十二條敏捷宣言：

我們的首要任務是透過儘早地、持續地交付可評價的軟體來使客戶滿意。

樂於接受需求變更，即使是在開發後期也應如此。敏捷過程能夠駕馭變化，從而為客戶贏得競爭優勢。

頻繁交付可使用的軟體，交付間隔越短越好，可以從幾個星期到幾個月。

在整個專案開發期間，業務人員和開發人員必須朝夕工作在一起。

圍繞那些有推動力的人們來構建專案。給予他們所需的環境和支援，並且信任他們能夠把工作完成好。

與開發團隊以及在開發團隊內部最快速、有效的傳遞資訊的方法就是，面對面的交談。

可使用的軟體是進度的主要衡量指標。

敏捷過程提倡可持續發展。出資人、開發人員以及使用者應該總是共同維持穩定的開發速度。

為了增強敏捷能力，應持續關注技術上的傑出成果和良好的設計。

簡潔——最大化不必要工作量的藝術——是至關重要的。

最好的架構、需求和設計都源自自我組織的團隊。

團隊應該定期反思如何能變得更有戰鬥力，然後相應地轉變並調整其行為。

敏捷宣言是為銀河系帶來和平以及維護各自的平衡所邁出的很重要一步。

在很長的時間裡，相比此前基於流程和機械化的方式，這是第一次基於文化和“人性”來將不同的關鍵專案干係人連線在一起的方式。

人們開始互相交流，進行基本的碰頭會議，並開始不斷的交流意見和看法。

他們開始意識到他們是有著很多比想象中還多的共同點，客戶也開始成為他們之中的一員，而不再是像以往一樣只是往專案砸錢然後開始求神拜佛祈求一切順利如願。

3）弊端

雖然敏捷開發大幅提升了軟體開發的效率和版本更新的速度，但是

它的效果僅限於開發環節

。我們發現，運維那邊，非常落後的手動部署上線，就成了新的瓶頸。

運維工程師，和開發工程師有著完全不同的思維邏輯。

運維團隊的座右銘

，很簡單，就是“

穩定壓倒一切

”。運維的核心訴求，就是不出問題。

什麼情況下最容易出問題？發生改變的時候最容易出問題。所以說，運維非常排斥“改變”。

於是乎，矛盾就在兩者之間集中爆發了。

這個時候，神秘的主角DevOps，隆重登場了。

三、DevOps開發

1。 背景

到了當今時代，網際網路的網民在海量增加，在這種背景下，誕生了眾多的網際網路大廠，以及多款現象級產品，比如微信、淘寶、抖音等等，網際網路的競爭也越來越激烈。

快速迭代產品，快速佔領市場，快速佔據使用者心智成為了各網際網路公司的目標，這個時候，就對產品開發提出了更高的要求，需要能夠對產品持續開發、持續整合、持續測試、持續部署、持續監控，需要每天每時每刻都可進行新版本的上線。

開發團隊與運維的矛盾，是時候環節一下了，怎麼緩解呢？那就把它們也搞到同一戰線吧：

2。 特點

這種模式下，將“更快”，又提升了一個層次：使用者可以很早地就得到最終產品或服務的一部分進行實際體驗，從而可以儘快的把發聵傳遞迴需求管理團隊和產品研發團隊。

而這的一切，都需要歸功於：DevOps將開發、測試、運維都拉到了同一戰線！

敏捷有自己的宣言，而DevOps也有著自己的清單：

DevOps清單：

開發團隊和運維團隊之間沒有障礙，兩者皆是DevOps統一流程的一部分。

從一個團隊流轉到另一個團隊的工作都能夠得到高質量的驗證。

工作沒有堆積，所有的瓶頸都已經被處理好。

開發團隊沒有佔用運維團隊的時間，因為部署和維護都是處於同一個時間盒裡面的。

開發團隊不會在週五下午5點後把程式碼交付進行部署，剩下運維團隊週末加班加點來給他們擦屁股。

開發環境標準化，運維人員可以很容易將之擴充套件並進行部署。

開發團隊可以找到合適的方式交付新版本，且運維團隊可以輕易的進行部署。

每個團隊之間的通訊線路都很明確。

所有的團隊成員都有時間去為改善系統進行試驗和實踐。

常規性的引入（或者模擬）缺陷到系統中來並得到處理，每次學習到的經驗都應該文件化下來並分享給相關人員，事故處理成為日常工作的一部分，且處理方式是已知的。

總體來看，在人力成本如此之高、市場競爭如此之激烈、使用者需求變化如此之頻繁的情況下，

DevOps是大廠必須選用的一條路。

四、結語

好了，以上就是今天為大家總結的內容了，你問我瞭解這些有啥用？

作為網際網路界走在最前沿的產品經理，你說你該不該瞭解這些個玩意；然後作為顏值與智商兼備，然後日夜期盼世界和平的碼農們，有這樣一個機會，擺在你們面前，你們難道不應該珍惜麼？

曉莊同學；公眾號：曉莊同學產品筆記，人人都是產品經理專欄作家。網際網路老兵，各大平臺專欄作者。

本文原創釋出於人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。