開發(fā)常說的「devops」到底是什么？

其實(shí)最早的時(shí)候，devops中，"dev"指的是開發(fā)人員，"ops"指的是運(yùn)維人員。它是為了提升運(yùn)維效率的一種協(xié)作方法和工具。（這是比較狹義的解釋）

上古時(shí)期，當(dāng)成立一個(gè)新項(xiàng)目，前端想發(fā)布到線上時(shí)，操作流程非常繁雜：

1、登錄到服務(wù)器，配置好域名和項(xiàng)目首頁的映射關(guān)系。

2、配置好靜態(tài)資源緩存機(jī)制。

3、上傳前端代碼到服務(wù)器的指定位置

4、在服務(wù)器執(zhí)行構(gòu)建命令，生成前端構(gòu)建后的代碼。

等等。。

其實(shí)以上很多步驟都是“運(yùn)維”的工作，如果后面項(xiàng)目越來越多，每個(gè)項(xiàng)目都這樣配置一遍，效率是非常低的。

所以很多“持續(xù)集成/持續(xù)交付”平臺(tái)就應(yīng)運(yùn)而生了。

持續(xù)交付平臺(tái)會(huì)代替很多運(yùn)維工作，讓開發(fā)人員更關(guān)注于自己的業(yè)務(wù)代碼。

比如騰訊的coding平臺(tái)，當(dāng)你新成立一個(gè)前端項(xiàng)目時(shí)，只需要在平臺(tái)上面建立一條發(fā)布“流水線”，就可以把代碼發(fā)布到線上了。

但這只是通過自動(dòng)化工具解決了“運(yùn)維”方面的效率問題，產(chǎn)品和開發(fā)之間的協(xié)作效率問題依然沒有解決。

比如說，當(dāng)開發(fā)寫好代碼，想發(fā)布到測試環(huán)境讓產(chǎn)品驗(yàn)收時(shí)，該如何通知到產(chǎn)品？每次都要私聊他嗎？

再比如當(dāng)開發(fā)完成需求并發(fā)布到線上后，過幾個(gè)月后，如何能追溯到哪個(gè)需求對(duì)應(yīng)哪塊代碼？

還有開發(fā)評(píng)工時(shí)記錄在哪里？

后來，devops強(qiáng)調(diào)的是高效組織團(tuán)隊(duì)之間如何通過自動(dòng)化的工具協(xié)作和溝通來完成軟件的生命周期管理，從而更快、更頻繁地交付軟件。這是比較廣義的解釋。

這就需要一個(gè)一體化的項(xiàng)目管理工具了，能把整個(gè)軟件生命周期串起來。

各大云廠商其實(shí)都有提供devops一體化平臺(tái)，個(gè)人覺得阿里做的比較好??

從產(chǎn)品提一個(gè)需求，到需求上線，是一個(gè)閉環(huán)。

需求能跟人關(guān)聯(lián)，也能跟代碼關(guān)聯(lián)，也能跟上線的構(gòu)建產(chǎn)物關(guān)聯(lián)，還有自動(dòng)反饋消息到IM工具、郵箱等等。