我們的目標是：一天部署50次
aws推出的devops定製服務 —— 部署在手天下我有
一個完整的Devops流程至少由計劃 - 開發 - 測試 - 部署 - 監控 5個步驟的循環組成，然而以Amazon為代表的雲廠商們顯然並不這樣認為。Web開發發展到今天，你甚至可以在一臺樹莓派上完成計劃開發和測試的工作，然而你需要將打包好的應用部署到有公網ip的服務器上，並將你閃閃發光的域名指向它才可以被廣大用戶訪問到，Amazon們知道要保證7*24的服務，你需要穩定的網絡、帶寬和服務器，這可不是一臺樹莓派能搞定的，大部分正常人會考慮租用服務器，然而競爭日趨激烈，Google Cloud，Azure，阿里、騰訊都虎視眈眈，價格大戰幾乎不可避免，顯然要想持續為用戶提供價值（租服務器賣錢）沒什麼比一套綁定了自家雲服務的一站式部署服務更貼心的了，只要控制住用戶的部署環節，即便客戶想換家便宜的雲服務商也沒那麼容易，這就是現在雲服務商都紛紛轉行開始做起Devops生意的原因——我們的目標是：讓客戶一天部署50次（只有在我們的雲環境下才做得到）！
是的，Amazon重新定義了Devops只是饞你的錢，作為一名資深雲服務羊毛黨，當然不會將自家服務建立在雲服務商的部署流程上，下面就帶你搭建一套基於quickbuild的持續集成和部署流程，輕鬆將你的項目在任何時間部署到任何雲，讓我們開始吧。
Quickbuild 基礎
相信不少人對quickbuild很陌生，但是如果換成jenkins，相信知道的人又會多一些。如果你已經知道jenkins，那麼可以跳過這一段，你可以將jenkins看作是quickbuild的開源版本。如果你還沒聽過，接著往下看。我第一次接觸持續集成和持續部署的概念是在12年左右，那時我們自己的上線工具還很簡陋：將php代碼提交到svn後，打開上線系統（一個項目目錄列表+登錄授權系統）勾選要上線的文件，點擊發布按鈕，rsync會將勾選的文件同步到線上服務器，如果代碼語法有問題或者忘了部署一些新增的依賴，線上就報錯了，偏偏我們的報警系統也很簡陋——5分鐘一次的郵件報警，更可怕的是如果有兩個人一起上線的話，彼此都不知道對方上了什麼鬼，只能一臉茫然的看著報錯郵件。一個剛剛畢業的小孩，就這樣被折磨得謝了頂。
看髮量就知道你是高級工程師
彼時微博風頭正勁，偶然一個機會接觸到他們的上線工具——quickbuild，一眼被驚豔到了。界面簡潔，功能強大，不需要勾選要上線的文件，所有的上線操作只需要點一個綠色的小三角，可以看到是誰在什麼時間上線了哪些內容，部署前有語法檢測和單元測試避免線上故障，甚至可以結合jira提案自動生成上線報告。
發佈歷史一目瞭然
quickbuild將上線被分為兩個階段——集成（將代碼打包）和部署（將打包好的代碼上傳到服務器），而將此過程不停重複，就是所謂的持續集成和持續部署了，聽起來高大上的名詞，背後往往是非常簡單的概念。在摸索了兩天後，我將自己負責的項目率先遷到了quickbuild。而今，當年的項目從部署在實體服務器到部署在虛擬機，再經過容器化變為了運行在kubernets上的pod；從apache+php5.mod到nginx+php-fpm再到resty+php-fpm直至今天的kong ingress + php-fpm/swoole，可以說部署的環境和工具都發生了翻天覆地的變化，然而讓我吃驚的是這套基於quickbuild的上線流程竟可謂堅如磐石，有些步驟甚至從第一天投產起就從未發生過變化，同時它又能很好地適應日新月異的部署環境，這在瞬息萬變的代碼世界堪稱奇蹟，不得不衷讚歎其創造團隊超越時代的眼光和思想。
在quickbuild面前誰不是個渣男呢
工作流引擎
安裝啟動非常簡單，不做贅述，讓我們來看如何配置一個工作流引擎。
配置項
quickbuild採用帶有繼承關係的配置項來表示要部署的項目，繼承的好處是可以將公司所有項目的共同部分放到父配置中，子配置只需要根據自己的實際情況覆寫幾個變量，即可完成一個新項目的配置工作。OO這種對擴展開放，對修改關閉的設計思想不僅僅可以用來寫代碼，還可以用來配置上線工具，沒想到吧。
具有繼承關係的配置項
對於配置，一個典型的用法是按照項目劃分出父配置，然後按照部署環境分成測試(qa)、迴歸(rt)和生產(prod)，每個配置項都可以單獨為人員按照角色配置發佈權限，這樣就不會因為開發人員對公司心懷不滿胡亂發佈代碼了，至少要串通測試和運維一起作案（逃）
按照環境劃分配置項
配置
每個配置由Repositories（版本控制工具，如git、svn等），Steps（工作流配置），Variables（配置變量），Promotions（發佈管理）在內的幾個基本設置組成。
最關鍵的4個基礎設置
當你點擊構建按鈕時，quickbuild會按照Steps中配置的工作步驟逐一執行。一般配置的集成過程包含
- 遷出代碼：比如生產環境遷出最新的master分支，而測試環境可能需要指定要遷出的分支
- 依賴：對於我們的PHP項目來說，你可以並行執行composer和npm分別下載php和js的依賴
- 測試：你可以配置lint檢測你的語法，配置單元測試或集成測試
- 打包：將要部署的文件打包，打包可以做成zip、tar或是docker鏡像併發布到鏡像私服
自由組合出你需要的工作流
集成後你就得到了一個archive文件夾，裡面包含了要部署的文件，此時我們可以在構建成功後選擇自動部署或手動部署（promotion）這一步你可以自己定製，可以直接將代碼同步到線上，也可以同步到發佈服務器，還可以通過kubectl或直接調用k8s apiserver的方式滾動更新在k8s中的pod。
發佈了哪些內容一目瞭然
部署後
在發佈後，你還可以發送一封郵件，報告本次上線關聯的jira提案和包含的變更。提起jira，這又是一個讓人頭禿的話題呢，恐怕一篇文章都說不完，先挖個坑。總之上線從未如此輕鬆，如果你還在用讓人頭禿的上線方式，不妨試一試哦。
寫在最後
這是玩兒轉Devops系列文章的第一篇，後續我會以文章中的CI/CD步驟為主線，搭建一個適合中小公司的Devops工作流，下面就跟工頭一起開始你的Devops之旅吧
