目前很多大廠如阿里、騰訊、百度、頭條、滴滴、美團等公司內部都在做DevOps，那么DevOps是什么？為什么大廠都對其趨之若鶩？DevOps應該怎么做？

首先我們來講講DevOps是什么？

DevOPs是一種方法論。DevOps=Developers+Operators，即開發(fā)團隊和運維團隊一體化，盡可能的為公司創(chuàng)造更多價值。

現(xiàn)在流行的做法是將兩個職能部門的人融合為一個職能部門，實現(xiàn)開發(fā)運維一體化，而早期的時候是兩波人分別承擔不同的職能，中期的時候是要求兩波人密切配合、快速迭代，這中間的變化取決于開發(fā)模式的轉變。

早期的時候是瀑布開發(fā)模型。因為互聯(lián)網上涌入的網民還不多，大家的關注點是能用、能解決問題即可，所以早期在需求評審階段產品經理給到的是完整、清晰、固定的需求，研發(fā)人員只需要根據需求在約定的時間點進行交差即可，迭代的頻率或許是1月1次，也或許是1個季度1次，研發(fā)聚焦于功能開發(fā)，在功能開發(fā)完成后交付測試團隊進行測試，測試團隊經過反復的測試與問題修復后，交付運維團隊進行上線，此后生產環(huán)境的可用性穩(wěn)定性等工作全由運維負責。

這種開發(fā)模式存在的問題是需求不能快速得到驗證，很有可能團隊花費半年的時間開發(fā)出來的東西早已經不適合市場了，也還有種可能是在開發(fā)階段研發(fā)需求理解不到位，等到后期驗證時發(fā)現(xiàn)有問題再去做調整耽誤整體工期。

中期的時候是敏捷開發(fā)模型。因為互聯(lián)網上涌入的網民開始增多，大家的關注點開始變成好用、好玩，而此時一些有遠見的人開始注意到互聯(lián)網紅利，投身于互聯(lián)網，此時的開發(fā)模式演變成了敏捷開發(fā)模型。

敏捷開發(fā)模型面對的是頻繁的需求變化，要求快速開發(fā)。比較流行的實際案例則是Scrum、XP極限編程。在新迭代（一般2-6周）開始前，產品經理將需求拆分成具體的開發(fā)任務，研發(fā)人員進行任務認領，每日站會進行任務的review，直到開發(fā)完成，發(fā)布新的可用版本。

現(xiàn)在最流行的是DevOps。因為互聯(lián)網上涌入的網民在海量的增加（微信用戶已破11億），互聯(lián)網企業(yè)的競爭也開始變得激烈，同一塊蛋糕很多人來搶來分（電商領域的淘寶、京東、網易嚴選、拼多多、小鵝拼拼等），快速迭代產品，快速占領市場，快速占據用戶心智成為了各互聯(lián)網公司的目標，此時的開發(fā)模型變成了DevOps，需要持續(xù)開發(fā)、持續(xù)集成、持續(xù)測試、持續(xù)部署、持續(xù)監(jiān)控，每一次代碼的改動都觸發(fā)一次校驗，每天每時每刻都可進行新版本的上線。

那么DevOps應該怎么做呢？因為涉及到整個軟件開發(fā)的生命周期，而軟件的起點之一便是代碼，所以常見的實現(xiàn)做法是從代碼倉庫視角入手（如Gitlab），研發(fā)人員從版本控制系統(tǒng)中拉取代碼倉庫，進行新版本的開發(fā)，功能開發(fā)完成之后，提交代碼合并請求MergeRequest，在合并請求中通過gitlab.ci的yaml文件編寫去觸發(fā)CI校驗，如代碼規(guī)范檢查、代碼安全檢查、單元測試等，CI校驗通過之后進行代碼合并到主干分支，觸發(fā)代碼編譯、打包、部署流程，將生成的產物如鏡像部署在預發(fā)布環(huán)境的物理機、虛擬機、容器中，經過小部分用戶校驗沒問題后再大范圍甚至全量發(fā)布。

而有的做法則是以整個服務的視覺來看待整個軟件生命周期，通過流水線將開發(fā)的代碼、合并代碼、單元測試、編譯打包、部署、集成測試、灰度發(fā)布、上線發(fā)布全串聯(lián)起來。研發(fā)人員從代碼倉庫拉取開發(fā)分支進行開發(fā)，開發(fā)完成后通過流水線發(fā)起合并測試部署上線流程，其它的代碼合并功能、編譯、部署、單元測試、集成測試、灰度發(fā)布、上線發(fā)布全都是其它組件以底層的能力在去做支撐。

總體來看，在人力成本如此之高、市場競爭如此之激烈、用戶需求變化如此之頻繁的情況下，DevOps是大廠必須選用的一條路。

目前DevOps已日趨激烈成熟，阿里的云效、騰訊工蜂等產品不僅內部自用，而且已在公有云部署發(fā)布，越來越多的傳統(tǒng)企業(yè)和新創(chuàng)企業(yè)也開始接受并實施DevOps，DevOps工程師也成為當下最炙手可熱的崗位之一，對DevOps你心動了嗎？心動就趕快行動吧～