一.DevOps簡介
DevOps 是Development 和Operations 的組合，也就是開發和運維的簡寫。
DevOps 是針對企業中的研發人員、運維人員和測試人員的工作理念，是他們在應用開發、代碼部署和質量測試等整條生命周期中協作和溝通的最佳實踐，DevOps 強調整個組織的合作以及交付和基礎設施變更的自動化、從而實現持續集成、持續部署和持續交付。
DevOps 四大平台：代碼托管(gitlab/svn)、項目管理(jira)、運維平台(騰訊藍鯨/開源平台)、持續交付(Jenkins/gitlab)
1.1什么是DevOps
1.2 為什么要推廣DevOps？
DevOps 強調團隊協作、相互協助、持續發展，然而傳統的模式是開發人員只顧開發程序，運維只負責基礎環境管理和代碼部署及監控等，其並不是為了一個共同的目標而共同實現最終的目的，而DevOps 則實現團隊作戰，即無論是開發、運維還是測試，都為了最終的代碼發布、持續部署和業務穩定而付出各自的努力，從而實現產品設計、開發、測試和部署的良性循環，實現產品的最終持續交付。
1.3 DevOps 技術團隊
1.4 什么是持續集成(CI-Continuous integration)
持續集成是指多名開發者在開發不同功能代碼的過程當中，可以頻繁的將代碼行合並到一起並切相互不影響工作。
1.5 什么是持續部署(CD-continuous deployment)
是基於某種工具或平台實現代碼自動化的構建、測試和部署到線上環境以實現交付高質量的產品,持續部署在某種程度上代表了一個開發團隊的更新迭代速率。
1.6 什么是持續交付(Continuous Delivery)
持續交付是在持續部署的基礎之上，將產品交付到線上環境，因此持續交付是產品價值的一種交付，是產品價值的一種盈利的實現。
二.常見的代碼部署方式
2.1 藍綠部署
藍綠部署指的是不停老版本代碼（不影響上一個版本訪問），而是在另外一套環境部署新版本然后進行測試，測試通過后將用戶流量切到新版本，其特點為業務無中斷，升級風險相對較小。
具體過程：
1.當前版本業務正常訪問（V1）
2.在另外一套環境部署新代碼（V2），代碼可能是增加了功能或者是修復了某些bug
3.測試通過之后將用戶請求流量切到新版本環境
4.觀察一段時間，如有異常直接切換舊版本
5.下次升級，將舊版本升級到新版本（V3）
藍綠部署適用的場景：
1.不停止老版本，額外部署一套新版本，等測試發現新版本OK后，刪除老版本。
2.藍綠發布是一種用於升級與更新的發布策略，部署的最小緯度是容器，而發布的最小緯度是應用。
3.藍綠發布對於增量升級有比較好的支持，但是對於涉及數據表結構變更等等不可逆轉的升級，並不完全合適用藍綠發布來實現，需要結合一些業務的邏輯以及數據遷移與回滾的策略才可以完全滿足需求。
2.2 金絲雀發布
金絲雀發布也叫灰度發布，是指在黑與白之間，能夠平滑過度的一種發布方式，灰度發布是增量發布的一種類型，灰度發布是在原有版本可用的情況下，同時部署一個新版本應用作為“金絲雀”(小白鼠)，測試新版本的性能和表現，以保障整體系統穩定的情況下，盡早發現、調整問題。
“金絲雀”的由來：17世紀，英國礦井工人發現，金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會停止歌唱；而當瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發身亡。當時在采礦設備相對簡陋的條件下，工人們每次下井都會帶上一只金絲雀作為“瓦斯檢測指標”，以便在危險狀況下緊急撤離。
金絲雀發布、灰度發布步驟組成：
1.准備好部署各個階段的工件，包括：構建工件，測試腳本，配置文件和部署清單文件。
2.從負載均衡列表中移除掉“金絲雀”服務器。
3.升級“金絲雀”應用（排掉原有流量並進行部署）。
4.對應用進行自動化測試。
5.將“金絲雀”服務器重新添加到負載均衡列表中（連通性和健康檢查）。
6.如果“金絲雀”在線使用測試成功，升級剩余的其他服務器。（否則就回滾）
灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。
灰度發布/金絲雀部署適用的場景：
1、不停止老版本，額外搞一套新版本，不同版本應用共存。
2、灰度發布中，常常按照用戶設置路由權重，例如90%的用戶維持使用老版本，10%的用戶嘗鮮新版本。
3、經常與A/B測試一起使用，用於測試選擇多種方案。
2.3 滾動發布
滾動發布，一般是取出一個或者多個服務器停止服務，執行更新，並重新將其投入使用。周而復始，直到集群中所有的實例都更新成新版本。
2.4 A/B測試
A/B測試也是同時運行兩個APP環境，但是藍綠部署完全是兩碼事，A/B 測試是用來測試應用功能表現的方法，例如可用性、受歡迎程度、可見性等等，藍綠部署的目的是安全穩定地發布新版本應用，並在必要時回滾，即藍綠部署是一套正式環境環境在線，而A/B測試是兩套正式環境在線。
然后基於評比結果，選出最終優勝的方案。
三.代碼部署流程
開發把代碼提交到gitlab，運維或開發用jenkins從gitlab clone代碼，也可以是jenkins 通過ssh連到部署服務器clone代碼，使用sonarqube對源碼進行掃描，掃描完后沒有問題，使用maven、ant等工具編譯代碼，編譯好后生成jar包或war包，用scp、ansibel、SaltStack等工具分發編譯好的jar包或war包，從haproxy或nginx等負載均衡器下線要分發的服務器，停止web服務，代碼替換，啟動web服務，測試web服務器url是否能正常訪問，從haproxy或nginx等負載均衡器上線服務器。