本次分享的主題是從devops看自動化發(fā)布，自動化發(fā)布實際上是devops閉環(huán)的末端應用部署，實現應用部署的自動化聽起來美好，但在背后與整個流程有著千絲萬縷的關系，想弄明白就要從整體角度來理解。那么在自動化部署帶來的便捷背后遵循著什么理念，或者說它構成了什么體系中的一環(huán)，接下來會為大家講解。

被玩兒壞的敏捷開發(fā)——Agile：在介紹devops之前首先要說一種開發(fā)模式，那就是敏捷模型，敏捷開發(fā)這個詞兒在我國已經被玩兒壞了，因為很多啥都不懂的無良老板命令員工去開發(fā)一個項目，只顧圖快，然后就搬來了敏捷開發(fā)這個筐，啥啥都往里裝，搞得就跟上了敏捷開發(fā)就真的能畝產萬斤一樣。那么真正的敏捷開發(fā)是什么樣呢，比如我之前有一個項目就是敏捷開發(fā)，每天早晨會開一個晨會，討論一下當前進度，看一下哪些需求還沒做，一般會有一面墻，上面貼滿了寫著需求的小紙條，產品人員確定細化需求后與主要開發(fā)者確定需求體量，需求上墻后會分為undo、doing、test幾個區(qū)域，當天完成的工作會提交到git上做一下集成，完成的需求會有測試人員提測，一般來說一個版本的需求發(fā)布周期為兩個星期，從需求到開發(fā)到測試部署這樣每個版本的間隔盡量縮短，類似于微積分，把巨量不規(guī)則的工作理出條理提高工作效率，這就是對敏捷開發(fā)的一個粗略描述。

那么為什么敏捷模型突然流行起來，為什么項目都用敏捷模型呢？隨著技術的發(fā)展，軟件開發(fā)周期越來越短，競爭對手應對市場需求越來越快，每個人都在圖快，每個人都希望能夠快速把握市場，在上層決策對開發(fā)需求起主導作用時，敏捷模型作為最好的選擇才會突然流行起來。

剛才有一句話，就是隨著技術的發(fā)展，究竟是什么技術在支撐著我們，讓我們開發(fā)周期越來越短，應對市場需求也越來越靈活呢？敏捷模型實踐的背后技術支撐正是一個叫做devops的理念，devops并不是什么工具，不是什么語言，也不是什么產品，它是一種哲學思想，也就是說當你遵循使用devops哲學思想之后，你就可以實現非常頻繁快速的應用迭代和發(fā)布，devops可以理解成為溝通development和operations之間的橋梁。

Development指代的是開發(fā)環(huán)節(jié)，這里我們把產品和開發(fā)放在一起統(tǒng)稱為development，他們的融合改造是通過敏捷模型實現的，那么devops則實現了開發(fā)和運維的融合，這個詞也正是取用于此，是dev-ops的結合。

Devops至今沒有一個權威的定義，搞得各家都有各家的說法，我提煉了一下它大概具有如下幾個特性，一切自動化，縮短周期應對靈活需求，和溝通各環(huán)節(jié)。用一個圖來描述devops，左邊是dev，右邊是ops，下面提供了一個反饋機制，其中穿插著精實，快速迭代，敏捷開發(fā)等思想，這些統(tǒng)稱為devops，它也可以說是一種文化。

那么具體點兒來說，devops在我們身邊有哪些看得見摸得著的東西呢？

比如說我們用的Windows系統(tǒng)，如果你加入到了Windows的內部預覽計劃的話你會發(fā)現三四天就有一個很大的更新，平常玩的游戲也是，三天一個小補丁；三天一個小補丁。這些產品如今能發(fā)布的這么快，這好像和我們傳統(tǒng)軟件工程是不一樣的，比如我有個上海的哥們兒，他們公司使用的是瀑布模型，在他們公司里發(fā)布一次的成本很高：比如說他們產品現在要上線了，所有人要卡著時間點倒計時，所有的開發(fā)人員、運維人員、質量保證、架構師都齊聚一堂，大家一起加班到凌晨，可能這個軟件要部署很多次，第一次部署發(fā)布大家會遇到很多問題，所有工程師要hotfix，架構師要不停診斷原因，這樣跑需要不停打電話解釋，所有人折騰到很晚，項目成功上線，看到所有用戶涌進來，他們可以看到各個儀表上數值上漲，這個情景看起來很帥，但是不要忘記了，讓這么多工程師加班一宿的成本是相當高的，也就是說，在傳統(tǒng)軟件工程中，一次發(fā)布的成本很高，在發(fā)布前所有人都要進行代碼整合，重新進行測試，發(fā)布過程中所有人都要在場，參與診斷問題，在發(fā)布成功之后，所有人還要監(jiān)視程序是否能夠平穩(wěn)運行下去，而敏捷我又提到了，它幾星期就是一個周期，幾星期就需要發(fā)布一次，如果每次發(fā)布成本像發(fā)射火箭這么高，我們就不可能每星期就發(fā)射一次火箭，而在devops理念中，每星期發(fā)射一次火箭則變成了可能。

一個理念，不一定對：為什么這么說呢，一個理念好理解，我們剛才解釋了這么多，那么為什么說不一定對呢，我們來開一下腦洞，devops作為一個理念，一種文化，一套模式，可以說是我們當今這個時代孕育出來的一個產物，它符合我們現代社會快節(jié)奏的主旋律，它也慢慢變成了IT界的一個共識，也就是說它紅了，但是任何事物都有一個生命周期，比如網紅，早期網紅鳳姐，上電視上雜志，現在鮮有人提及，甚至連千萬級別粉絲的微博都注銷了，很難說是她娛樂了大眾還是大眾消費了她，我想表達的是，devops是建立在當代潮流基礎上，如果社會風向變了，它也就不適用了。有一種可能是devops也會隨著時代進步，但忒修斯之船悖論是它的歸宿，就是說每次給這艘船更換一個部件，等所有部件都被陸續(xù)更換過一遍了它是不是還是原來那艘船？到時候devops還應不應該叫devops？

或者有另一種可能，看過三體的同學應該知道有一個技術爆炸的概念，我們遠的不說，就拿手機舉例子，上世紀末的大哥大BP機，到后來的諾基亞，再到后來的iPhone4，再看看現在我們手里的手機，只是短短30年從語音通話到現在面對面視頻和百花齊放的APP，完成了如此巨大的變化，當然這也得益于網絡技術的快速發(fā)展，從2G幾K的上網速度到現在的4G+，再到即將邁入的5G邊緣化計算物聯網時代，不得不說我們正處于技術爆炸之中，但是此爆炸的余熱正隨著摩爾定律的失效而降溫，而下一次爆炸正在醞釀，隨時可能到來，那就是量子技術，量子計算機一旦發(fā)展起來，算力將遠超現有架構的機器不知道多少倍，那會給我們現在熟悉的一切帶來毀滅性的影響，例如現有的密碼體系將不堪一擊，密碼只是通過數學概率保證安全性，高安全性的密碼以現在的機器可能算幾年都算不出來，而量子計算機可能瞬間就破解了，靠算力維持的比特幣挖礦體系將在分分鐘內把所有礦挖了出來，但區(qū)塊鏈體系并不會崩潰而會進化，這個各位如果有興趣可以單開一次分享討論這個事兒。    

人工智能，現在是人工智障，如果算力上去了就真的有可能通過算法描述出來真正的AI，從各方面完全超越人類，搭配量子網絡，承載更大數據量，更多形式的傳輸，到時可能只剩云計算了，我們沒必要，也不需要在家放一臺笨重的計算機，只需要有一個終端，比如谷歌的搭載Chrome OS的Chrome Book，它的設計理念就是數據完全存在網絡上，而這臺上網本就是一臺硬件級別的瀏覽器，隨時隨地在任何一臺Chrome Book上登陸你的賬號，就能完整體驗谷歌全家桶給帶來的個性化服務，再比如微軟公司的游戲模擬飛行2020，幾乎完整還原了地球樣貌，游戲容量超過70個PB，玩家不可能下載到本地計算機，只能聯網加載所視區(qū)域的游戲內容，這就是云計算的未來，這也可以單開一個分享講，那么我們會不會就像《阿凡達》里潘多拉星球一樣，有一棵世界樹，我們的頭發(fā)連到樹上就加入到了龐大的云中，我們就像《頭號玩家》一樣，完全進入到了另一個世界，身臨其境。    

這樣的生活是我們現在不可想象的，但十幾二十年后完全有可能實現，到時候我們看這些可能就跟我們家里老人看智能手機一樣，根本玩兒不轉了。所以每次技術爆炸的間隔越來越短，每次帶來的技術進步也越來越大，而量子我們只是應用其特性就能帶來翻天覆地的變化，如果基礎科學發(fā)展到完全弄明白量子技術是怎么回事了，那將會開啟另一個時代了。所以在這種背景下，大家想想IT界還會是現在這種節(jié)奏嗎，我們的devops還會存在嗎？所以我們說它能一直對下去嗎？將來它可能作為一個概念載入歷史，但不可能屬于將來，以前連計算機都沒有，更不可能屬于以前。Devops屬于今天，不屬于明天，更不屬于昨天。

有點扯遠了，說回來我們在傳統(tǒng)發(fā)布過程中都是優(yōu)先保證我們應用程序本身正常，例如我們需要去某某云買一臺新的服務器，然后在服務器上安裝數據庫系統(tǒng)，部署我們的軟件，安裝Web服務器，把各種需要的參數都設置調節(jié)好，完成好數據庫的播種，解決相關的問題，最后才能完成這次發(fā)布，如果發(fā)布完成后過了幾天我們的程序掛了，出了點問題，我們第一反應都是服務器出問題了，我們只需要到服務器上去看看問題的日志，解決這個問題，保證服務器正常就可以了，這是傳統(tǒng)軟件工程的方法。但是在devops理念中，它有一個非常重要的觀念就是一切部署發(fā)布都要實現自動化，所謂自動化是什么意思呢，就是說每一次發(fā)布我們都不在乎，服務器也不在乎，我們只在乎一件事，就是我們的代碼和管道。

代碼我們都理解，我們經常使用git來管理我們的代碼，審查pull request合并代碼，管理代碼分支。管道又是什么呢，管道又叫流水線，這要說回敏捷模型，敏捷就是一個大的流水線，有反饋人員提交了反饋，進入開發(fā)人員的工作工單中，產品組成員按照優(yōu)先級排好，開發(fā)組成員完成這些工單。但這里有一個細節(jié)，工單一旦完成，合并到了主分支中，發(fā)布是誰在做呢？并不是人在發(fā)布，而是流水線本身就有發(fā)布功能，而且流水線本身還有代碼檢查功能，優(yōu)先保證代碼和管道，就是要在每一次發(fā)布的時候是全自動的完成代碼檢查和自動部署，為了保證這一點，實際上背后有非常復雜的技術支撐，有PaaS層的云計算，有容器技術，有DSC期待配置方法，還有很多哲學思想，比如之前我們有大神講解的Kubernetes管理docker就是其中一種。

我們說回這個圖來解釋流水線，流水線是一條管道而真正的功能是各功能組件去做的，流水線負責調用這些組件完成一個閉環(huán)的協(xié)調。最重要的為了保證代碼的自動檢查和自動部署，其中最核心的兩個概念是Continuous Integration和Continuous Delivery，聽到這你可能覺得很玄乎，什么。。。。。。我們暫且叫它CI和CD吧，簡單來說，CI是保證你的代碼每一次都能通過集成，CD是保證你的代碼可以自動化部署，你可能還是覺得這是什么玩意兒？好玄乎兒啊！

在傳統(tǒng)軟件發(fā)布過程中，例如明天就要發(fā)布了，今天每個人各負責了幾個模塊，顯然今天晚上我們要把所有人寫的模塊整合到一起，結果一整合的時候發(fā)現有問題，可能這個模塊我寫了一遍，他也寫了一遍，我們一塊寫了兩遍，而另一個模塊誰都沒寫到；多帶帶編譯每個模塊都是0 error 0warning，結果整合到一起就發(fā)現幾百個error幾千個warning，這是傳統(tǒng)軟件工程中非常常見的一個現象，就是各組開發(fā)人員都完成了自己所需要的開發(fā)時，我們一般都把每個組開發(fā)的各個組件整合在一起，這個過程叫做集成，集成的過程中非常容易產生巨量的錯誤，我們稱這種過程叫做集成地獄，之所以一次發(fā)布成本這么高，就是為了解決集成地獄中這些巨量的錯誤。

為什么CI可以解決它呢，CI是持續(xù)集成，也就是說我和我的同伙一起要寫一個項目，可能我要寫用戶賬戶管理模塊，同伙要寫音樂管理模塊，比如我們要寫音樂商店的話。如果我們在臨上線前一天再集成我們的軟件，那么我們一定會GG，假如我們在開始寫整個項目的第一天，就保證每個人寫的每次一代碼提交都能夠讓代碼穩(wěn)定運行起來，也就說每次一在使用git commit的時候，都會有一個自動化的工具，這個工具將對我們代碼嘗試進行整合，實質上工具一般都會運行你的編譯和你的集成測試、單元測試等，一旦工具發(fā)現，任何一次commit無法讓代碼通過它的整合，工具就會拒絕本次代碼修改，從而保證我們代碼任何一個時間內都是干凈的，這就是CI的核心思想，它能夠將我們的事故在它最初將要發(fā)生的時候以最低的成本警告我們的每一個開發(fā)者，這樣我們就能夠在最早的時間內得知什么時候出現的故障，修正這些故障，從而保證我們整個集成流水線工作非常順利，任何一個時刻，我們找任何一份代碼，都可以完成我們的項目，而我們的代碼則在變得越來越好。

CD又是什么呢，CD是Continuous Delivery持續(xù)交付，我們知道發(fā)布一次軟件成本很高，CD就是自動化這個過程，對于任何一次通過CI的代碼修改都會觸發(fā)CD管道，CD將全自動的取出在CI過程中編譯好的項目，部署到你的服務器里，可以簡單理解為自動化發(fā)布正是CD的一個實現。

在我們完善配置了CI和CD實現了Devops哲學思想之后，服務器只不過是我們運行代碼的一個終端而已，我們每天只維護好我們的代碼，而代碼是直接影響著我們的服務器的，假如我們服務器掛了的話，那唯一出現問題的地方就是我們的代碼啊，我們把代碼就要修正好，然后重新跑一遍CI和CD管道，觸發(fā)自動部署，很快就有新的服務器回來了，而且新的服務器就不會遇到之前掛的這種問題，假如公司有了新的成員，他只需要直接對代碼做貢獻就可以了，他甚至連開發(fā)環(huán)境都不需要安裝，而他所做的貢獻一旦被CI檢查通過，就會觸發(fā)CD，CD的工作就是直接部署到全球的用戶中，這樣所有的用戶很快第二天就會收到一個更新，他們安裝更新后就會享受到新來的內個人做的最新的代碼貢獻，在devops理念中，實際上運維成本是非常低的，一般在運行CD管道的過程中，整個環(huán)境都會被重新創(chuàng)建，而你需要保留的數據則會仍然保留，伴隨著devops的發(fā)展，我們軟件工程流水線中成本越來越低，而云計算技術的進一步成熟，paas技術，saas技術的普及，又進一步普及了devops。在今天的IT中，開發(fā)者真的不需要在乎運維，他也并不需要手動的去買一臺服務器在上面安裝mysql，他只需要在乎好自己的業(yè)務邏輯，我寫好自己的代碼，而代碼的檢查和自動部署交付到每個用戶手中，都由非常成熟的devops理念全自動化的完成好。

接下來簡單介紹一下自動化發(fā)布的應用發(fā)布模塊，應用發(fā)布分兩套方案，一條是通過Web瀏覽器與系統(tǒng)交互，另一條則是為接入流水線準備的接口，在前期系統(tǒng)配置和腳本編寫全部完成后，發(fā)布將變得十分簡單。

在Web端的應用發(fā)布中，你需要建立一套發(fā)布模板，就是給每個步驟操作連起來形成一套編排，它描述的是一個整體的發(fā)布方案，里面包含了提前編寫好的操作步驟。隨后建立發(fā)布策略，發(fā)布策略則是一道橋梁，溝通了模板和計劃，建立策略時要先選擇對某個應用系統(tǒng)建立，建立的時候要選擇綁定哪個模板。你可以建很多個策略，但只能有一個默認策略，該業(yè)務系統(tǒng)建立發(fā)布計劃時，將使用默認策略綁定的模板進行發(fā)布。建立發(fā)布計劃時只需要選擇業(yè)務系統(tǒng)，然后填好版本號和計劃時間，版本號是唯一的，計劃時間則是計劃建立完成通過審核后將自動執(zhí)行的時間，上傳文件部分支持本地上傳和git鏈接上傳。如果點擊快速發(fā)布后則進入待執(zhí)行狀態(tài)，提交審核則會進入提審狀態(tài)，有權限的賬號可審核該計劃，保存草稿則會保存到草稿標簽中，為可編輯狀態(tài)。

計劃發(fā)布完成后點擊完成的計劃可以看到每個步驟的反饋結果，詳情頁中包含每一步操作執(zhí)行的時間，執(zhí)行輸出的內容及執(zhí)行結果，該結果可反饋流水線作為整個流程的閉環(huán)反饋。

END

更多精彩干貨分享

點擊下方名片關注

IT那活兒