編輯導語：隨著互聯網的發展，用戶對于產品的需求越來越高，更多的用戶追求“好看”和“好用”。本文作者分享了一種新的開發模式——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協議。
關鍵詞： 敏捷迭代已過時 現在大廠都在用DevOps開發模式
